ePartool: Mindestvoraussetzungen aktualisiert (PHP 7, MySQL 5.6)

Im August 2015 haben wir zum letzten Mal die Mindestanforderungen für den Betrieb des ePartool aktualisiert. Seitdem hat sich das Internet und seine Technologien bedeutend weiter entwickelt. Auch wollen wir Sicherheitsaspekte für Nutzende und Betreiber_innen im Auge behalten.

Aus diesem Grund haben wir uns entschieden, die Unterstützung für (sehr) veraltete Server einzustellen. Konkret bedeutet das, dass wir künftig als Datenbank-Server MySQL 5.6 oder neuer voraussetzen. Diese Version steht seit Februar 2013 zur Verfügung. Außerdem wird unsere Entwicklung nur noch mit PHP ab Version 7.0 getestet, das im Dezember 2015 erschienen ist. Derzeit wird das ePartool voraussichtlich noch auf Webhostings mit PHP 5.6 laufen; das werden wir jedoch nicht mehr garantieren.

Bei Problemen mit der Umstellung sind wir gerne behilflich.

Öfter mal was Neues: Antragsgrün 3.6.2, 3.6.3 und 3.6.4 in kurzer Folge erschienen [Update 25.04.]

Um mehrere Schwierigkeiten und Fehler bei Antragsgrün und dem dazugehörigen Installer zu beheben, erschienen in den letzten Tagen in kurzer Folge drei neue Versionen des Programms (https://github.com/CatoTH/antragsgruen/blob/v3/History.md). Wir empfehlen euch vorhandene Installationen bald zu aktualisieren.

[Update 25.04.] Der intensiven Weiterentwicklung ist derzeit geschuldet, dass mittlerweile die Versionen 3.6.5 und 3.6.6 freigegeben werden konnten. Es handelt sich hierbei um weitere Fehlerbehebungen und kleinere Verbesserungen, damit Antragsgrün „runder“ läuft.

Der direkte Download der aktuellen Version 3.6.6 befindet sich hier.

 

Hilfe, wir wurden gehackt! – Sicherheit bei digitalen Angeboten

Beinahe täglich werden Fälle von Sicherheitslücken, Hackingangriffen und „Datendiebstahl“ veröffentlicht. Davon auszugehen, dass man mit einem kleinen Internetangebot im Netz unattraktiv für Angriffe ist, erweist sich als Trugschluss. Es trifft große und kleine Plattformen, Onlinehops oder Websites gleichermaßen: Automatisiert werden Sicherheitslücken ausgenutzt, um Schadsoftware weiterzuverbreiten, Passwörter abzugreifen oder Spam zu verteilen. Schutzmaßnahmen gegen solche Angriffe müssen heute bereits Bestandteil der Planung eines Internetangebots sein. Aber auch im laufenden Betrieb lässt sich mitunter mit geringem Aufwand die Integrität der eigenen Plattform und die Sicherheit der Teilnehmenden deutlich erhöhen.

Grafik: GR8DAN, CC0 1.0 (https://creativecommons.org/publicdomain/zero/1.0/deed.de)

Der Aufbau neuer Angebote im Netz ist eine spannende und oft anspruchsvolle Aufgabe: Es gilt – zumeist in Kooperation – die detaillierte Funktionalität zu entwickeln, ein passendes Design abzustimmen und immer wieder in Bereichen, die vorher noch nicht ganz durchdacht waren, nachzusteuern. Während man sich in der Regel darüber im Klaren ist, dass sich die Inhalte einer neuen Plattform später noch weiter entwickeln werden, werden Aspekte wie Zugänglichkeit, Hilfen in leichter oder einfacher Sprache oder Sicherheit eher nur zu Beginn thematisiert und umgesetzt. Sobald das Web-Angebot online ist, wird diesen Aspekten kaum noch Beachtung geschenkt: Die Website scheint ja nach bestem Wissen abgesichert; und auch für Menschen mit mobilen oder visuellen Einschränkungen vorbereitet zu sein. Also nichts mehr zu tun, oder?

Der Schrecken ist groß, wenn man nach einer Weile merkwürdige Beiträge auf seiner Site entdeckt, wenn aus unerklärlichen Gründen der Speicherbedarf riesengroß wurde oder der Provider auf einen möglichen Einbruch hinweist.

Was bedeutet eigentlich ein Hackingangriff und warum ist er schlimm?

Hinter einem Angriff steckt nur selten eine konkrete Person. Meist handelt es sich um Programme, insbesondere spezialisierte Bots, die systematisch nach Schwachstellen auf Internetservern suchen. Diese Schwachstellen werden dann von den Bots selbst oder von Anderen für unerwünschte Aktivitäten ausgenutzt.

Konkret sind Schwachstellen z. B. häufig in Formularen zu finden, die die Nutzerdaten nicht sicher von unerwünschten Eingaben befreien: Eine Internetsite kann dadurch dazu gebracht werden, die Eingabe nicht als Daten, sondern als Befehle zu interpretieren. Aber auch das „Einklinken“ fremder Inhalte ist häufig zu leicht möglich.

Für Betreiber*innen von betroffenen Internetangeboten bedeutet das eine Reihe von Problemen. Am offensichtlichsten sind das Abfließen von personenbezogenen Daten, das Abgreifen von Login-Daten (weil viele Nutzer*innen dasselbe Passwort oft auch woanders verwenden), das Einbauen von unerwünschten Inhalten oder das Verteilen von Schadsoftware und Spam-Mails vom Server aus.

Auch kleine Websites sind für Angreifer*innen interessant: Sie können genutzt werden, um monatelang unbemerkt illegale Downloads in allen ihren Facetten anzubieten oder um die Website als Teil eines Botnets einzusetzen, das andere Server durch millionenfache Anfragen in die Unbenutzbarkeit kickt.

Neben den direkten Konsequenzen für die Website-Besucher*innen kommen überdies auch weitere Folgen auf die Betreiber*innen zu: Suchmaschinen könnten das Internetangebot auf ihre schwarze Liste gefährlicher Sites nehmen. Bei nachgewiesener Nachlässigkeit drohen Kündigung durch den Provider oder gar juristische Konsequenzen. Und nicht zu vergessen ist der Vertrauensverlust bei den Nutzer*innen, der lange Zeit nachhallen wird.

Das beste Mittel: Es gar nicht so weit kommen lassen

Betreiber*innen sollten sich daher schon vorher regelmäßig darum kümmern, dass das eigene Internetangebot aktuellen Sicherheitsanforderungen genügt. In den meisten Fällen wird man die zugrundeliegende Software auf dem Server nicht selbst entwickelt haben, sondern vorgefertigte Content-Management-Systeme wie Typo3 oder WordPress einsetzen. Die wichtigste Regel hierbei lautet, dass alle Updates dieser Systeme so schnell wie möglich auf dem eigenen Server eingespielt werden sollten: Wo Schwachstellen beseitigt wurden, hat ein Einbruchsversuch geringere Aussicht auf Erfolg. Oben genannte CMS werden beim Einrichten einer Website häufig durch Plug-ins erweitert, deren Qualität sehr unterschiedlich ist. Hier sollten diejenigen, die die Auswahl der Plug-ins treffen, auch die Zukunft im Blick haben: Wenn Plug-ins nicht mehr aktiv weiterentwickelt werden, ist davon auszugehen, dass früher oder später Schwachstellen auftreten, die dann nur mit professioneller Hilfe oder gar nicht mehr abgesichert werden können.

Gleichzeitig gibt es sehr hilfreiche Plug-ins, die beispielsweise Kommentarfelder auf mögliche Spambots überprüfen und so unerwünschte Nachrichten auf der eigenen Website sogar abwehren können.

Um zeitnahe Updates sicherzustellen, muss man nicht täglich alle Hersteller-Websites abklappern: Automatische Benachrichtigungen und Newsletter können behilflich sein. Eine Überprüfung auf Aktualisierungen benötigt häufig weniger als eine Stunde pro Vierteljahr – und sollte im besten Fall sogar täglich geschehen.

Sollte der Server nicht bei einem Webhosting-Provider angemietet worden sein, sondern selbst aufgesetzt und betrieben werden, dürfen die regelmäßigen Updates fürs Betriebssystem und die darauf laufenden Dienste wie Programmiersprachen, Web- und Datenbank-Server nicht vernachlässigt werden.

Zugangspasswörter von Nutzer*innen zu schützen, ist eine der Kernverantwortlichkeiten von Anbieter*innen. So muss z. B. verhindert werden, dass das System endlos neue Login-Versuche mit zufälligen Passwörtern zulässt. Gut ist es, wenn jeder fehlerhafte Login-Versuch eine kurze Zwangspause nach sich zieht. Damit können Angreifer*innen statt tausender Testballons nur noch wenige Anfragen im selben Zeitraum senden.

Auf älteren Internetangeboten werden Passwörter häufig nicht so hinterlegt, dass sie gegen Auslesen geschützt sind. Dies ist besonders problematisch, da Nutzer*innen oftmals dieselben Passwörter auf verschiedenen Sites verwenden. Ein Abgreifen auf einem Server zieht also Probleme auf weiteren Angeboten nach sich. Auf keinen Fall sollten Passwörter im Klartext abgespeichert sein. Durch das Bilden eines „Hash“, einer Art Quersumme bestehend aus mehreren Zeichen, können Betreiber*innen sogar ganz davon absehen, das tatsächliche Passwort auf dem Server zu hinterlegen: Die Kennworteingabe wird einfach ebenfalls „gehasht“ und mit dem hinterlegten Wert verglichen. Die Standards dieser Absicherung haben sich im Laufe der Jahre verändert. Bei älteren Sites ist daher möglicherweise der Umstieg auf einen neueren Standard ratsam. Das bedeutet jedoch, dass alle Nutzer*innen ihre Passwörter selbst einmal neu vergeben müssen: Neue Kennwörter unverschlüsselt per E-Mail zu verschicken ist dabei keine gute Idee.

Eine Verbindungsverschlüsselung zum Internetangebot sollte heutzutage Standard sein: Erst wenn Nutzer*innen eine Website über https statt über http aufrufen können, ist die Eingabe personenbezogener Daten und Passwörtern vor fremden Einblick abgesichert. Das gilt übrigens auch für die administrativen oder redaktionellen Logins, die man zum Pflegen der Inhalte braucht.

Hilfreich bei der Einschätzung von möglichen Sicherheitslücken sind Dienste wie das Mozilla-Observatory, das ein Internetangebot auf viele potenzielle Angriffspunkte überprüft und hilfreiche Infos zum Absichern gibt. Dabei muss man jedoch stets Augenmaß behalten: Nicht alle Absicherungen sind sinnvoll, wenn dadurch das Internetangebot nur noch umständlich nutzbar wird und Nutzer*innen möglicherweise fernhält.

Websites, die nicht mehr aktiv bespielt werden, sondern lediglich aus dokumentarischen Zwecken online erreichbar bleiben sollen, kann man überdies auch für lange Zeit absichern, wenn alle datenbankgenerierten Inhalte einmalig als statische Seiten exportiert werden und der Datenbankserver abgeschaltet wird. Da alte Projektwebsites in der Regel seltener aufgerufen werden, könnte ein Servereinbruch eine Weile unbemerkt bleiben.

Auch ist „automatisches Vergessen“, d. h. automatisiertes Löschen nach einem gewissen Zeitraum, ein guter Ansatz. Nicht mehr benötigte Daten werden entfernt, bevor sie für unerwünschte Zwecke missbraucht werden können.

Grundsätzlich gilt: Alle Daten, die nicht erhoben werden, können später auch nicht in fremde Hände abwandern. Das Prinzip der Datensparsamkeit ist also weiterhin eine sinnvolle Herangehensweise. Und Hand aufs Herz: Benötigt man von Nutzer*innen wirklich alle Angaben – von Alter über Stadtteil bis hin zu Hobbys?

Sich als Anwender*in schützen

Entgegen der landläufigen Meinung stellen nicht Antivirus-Programme das A und O der Absicherung dar, sondern regelmäßige Updates des genutzten Betriebssystems und der darauf laufenden Software. Ein Antivirus-Programm kann sogar neue Sicherheitslücken ins System reißen, so dass manche renommierte Entwickler*innen sogar gegen Antivirus-Programme wettern.

Passwörter sollten eher lang (14 Zeichen oder mehr) und mit einer Eselsbrücke zu merken sein. Kurze, aber kryptische Kombinationen führen eher dazu, dass man die Passwörter vergisst. Da Angreifer*innen in sogenannten Brute-Force-Attacken einfach alle möglichen Kombinationen durchprobieren, ist jedes Extrazeichen ein deutlicher Sicherheitszugewinn: Allein wenn man die 26 Buchstaben in Groß- und Kleinbuchstaben und die Ziffern 0-9 heranzieht, dann bedeutet jedes zusätzliche Zeichen eine 62-fach höhere Sicherheit! Empfehlenswert ist natürlich auch der Rückgriff auf Sonderzeichen an unerwarteter Stelle, dann sind Attacken auf Basis von Wörterbüchern weniger Erfolg versprechend.

Überraschend ist möglicherweise auch die Erkenntnis, dass Adblocker, also Browser-Erweiterungen, die das Einblenden von Werbung verhindern sollen, den eigenen Rechner auch besser absichern: Leider ist in der Vergangenheit gerade über die Werbenetzwerke, die selbst auf großen Onlinemagazinen zum Einsatz kommen, oftmals Schadsoftware an die Besucher*innen verteilt worden.

Und wenn doch einmal etwas schiefläuft

Wenn doch einmal ein Servereinbruch stattgefunden hat, dann gilt es dennoch Ruhe zu bewahren. Die betroffenen Dienste sollten so schnell wie möglich offline genommen werden, bis sie wieder in abgesicherter Weise zur Verfügung stehen. Auch den Nutzer*innen gegenüber sollte man transparent sein: Dies zeigt, dass man vertrauenswürdig bleibt selbst in Problemsituationen. „Security by obscurity“, also Sicherheit durch Verheimlichen vorzutäuschen wird langfristig nicht helfen. Auf Sicherheitslücken spezialisierte Suchmaschinen stehen in den Tiefen des Internets schon zur Verfügung.

CC BY 3.0 DE
Tim Schrock arbeitet beim Deutschen Bundesjugendring und ist innerhalb des Projekts jugend.beteiligen.jetzt zuständig für die Entwicklung digitaler Tools für Jugendbeteiligung.

Antragsgrün 3.6: Bessere Live-Diskussion

Das bei Jugendorganisationen mittlerweile häufig eingesetzte „Antragsgrün“ ist einer neuen Version 3.6.0 erschienen. Gerade für die gemeinsame Bearbeitung und Visualisierung von Anträgen und Texten bei Gremien oder Konferenzen finden sich in dieser Version hilfreiche Verbesserungen.

Weniger Konflikte, einfachere Diskussion
Mehrere überschneidende Änderungsvorschläge werden im Visualisierungsmodus übersichtlicher dargestellt. (Den Visualisierungsmodus erreicht ihr als Admins über „Änderungen einpflegen“.) Auch können Admins nun den Originaltext bearbeiten, ohne bestehende Änderungsanträge zu korrumpieren. Wenn es durch die Bearbeitung zu Konflikten mit bestehenden Änderungsanträgen kommen würde, können sie manuell aufgelöst werden.
Als ersten Schritt zu weniger konfligierenden Änderungsvorschlägen ist es nun auch möglich, dass Admins einen Änderungsantrag in den Originalantrag übernehmen und daraus eine neue Basisversion erstellen. Der ursprüngliche Textentwurf und der separat eingetragene Änderungsvorschlag verbleiben im System und können zum späteren Vergleich weiterhin aufgerufen werden. Auch hier gilt: Wenn es durch die Bearbeitung zu Konflikten mit weiteren bestehenden Änderungsanträgen kommen würde, können sie manuell aufgelöst werden.
Rechtzeitig für eine Live-Antragsberatung oder am Ende der Eingangsfrist können Textentwürfe/Anträge für weitere schriftlich eingehende Änderungsvorschläge gesperrt werden: Zu spät eingereichte Änderungen können somit künftig nicht mehr geschehen (oder übersehen werden).
Wenn Anträge/Textenwürfe oder Änderungsvorschläge eingetragen werden, werden Admins nun automatisch per eMail informiert. Die Neuigkeiten werden natürlich auch weiterhin in der ToDo-Liste im Backend angezeigt. Auch werden weniger Klicks benötigt: Antragsgrün zeigt bereits durch ein Pop-Over den Inhalt von Änderungsanträgen im Backend an.

Inhalte komfortabel exportieren
In Sammel-PDFs beginnt die Seitennummerierung nun bei jedem Antrag/ Textentwurf neu. Im Backend können nun Anträge mitsamt aller Änderungen als Sammel-PDF exportiert werden. Weitere Verbesserungen wurden auch beim OpenDocument-Export vorgenommen.
Der Export zu OpenSlides 2.1 oder neuer wird nun unterstützt: OpenSlides ist ein freies, webbasiertes Präsentations- und Versammlungssystem zur Verwaltung und Projizierung von Tagesordnungen, Anträgen und Wahlen einer Versammlung, ist aber bei der Antragsvisualisierung Antragsgrün deutlich unterlegen.

Installieren auch für kleine Webhostings leicht gemacht
Die für kleinere Webhosting-Pakete schon angepasste Version könnt ihr direkt unter https://www.hoessl.eu/antragsgruen/antragsgruen-3.6.0.tar.bz2 herunterladen. Die Variante für den eigenen, „richtigen“ Server gibt es wie immer direkt bei Github unter https://github.com/CatoTH/antragsgruen.

Bei dieser Gelegenheit wollen wir euch gerne ans Herz legen, auf eurem Webhosting zu überprüfen, ob PHP in der aktuellen Version 7.x zum Einsatz kommt. Unter älteren PHP-Versionen können Fehler auftreten – und 5.5 oder älter wird auch nicht mehr mit Sicherheitsupdates unterstützt. Euer Provider hat sicher bereits die Version 7.x einsatzbereit geschaltet.

Weitere Änderungen zu dieser Version und künftige Aktualisierungen erfährt man immer ganz aktuell auf Github in der Entwicklungshistorie: https://github.com/CatoTH/antragsgruen/blob/v3/History.md.

Wollen Sie nicht, dass diese Atombombe gezündet wird? Ja / Nein.

Zugegeben, das Beispiel aus der Überschrift ist etwas weit hergeholt. Aber es verdeutlicht die Herausforderungen bei der Entwicklung gut verständlicher Nutzerführung: Schneller als man denkt, hat man bei solchen Formulierungen die falsche Option angeklickt.

Auch im ePartool finden sich noch einige Funktionen, die verwirrend formuliert sind: Auswahlmöglichkeiten wie „Artikel noch nicht veröffentlichen: ja/nein“ oder „Zeige kein vollständiges Datum: ja/nein“ sind gerade durch die doppelte Verneinung sehr fehleranfällig. Dieses Problem betrifft nicht nur die Nutzer_innen, sondern auch alle, die an der Programmentwicklung arbeiten.

Zudem funktionieren die deutsche und die englische Sprache hier unterschiedlich – im Deutschen würde man auf die Frage „Du arbeitest am Samstag nicht, oder?“ ein „Nein, ich arbeite nicht“ antworten, im Englischen hingegen ein „Yes (I agree), ich arbeite nicht“.

In Vorbereitung auf die weiteren Sprachversionen des ePartool durchkämmen wir derzeit die Programmierung und Datenbankdefinitionen auf solche Stolperfallen.

Safer Internet Day 2017: Hilfe gegen Cybermobbing

Jedes Jahr am zweiten Tag der zweiten Woche des zweiten Monats (also immer ein Dienstag im Februar) wird der »Safer Internet Day« ausgerufen. Der Aktionstag findet weltweit statt und wird von der Europäischen Union unterstützt. Jedes Land setzt dabei eigene Schwerpunkte – in Österreich geht’s dieses Jahr dabei um „Fake News“, in Großbritannien sollen Sicherheitstipps per Emoji-Kurzgeschichten veröffentlicht werden. In Deutschland wurde für den SID 2017 das Thema „Cybermobbing“ ausgewählt.
Cybermobbing tritt in einer Vielfalt von Formen auf und ist bereits unterhalb der Schwelle zu Straftaten ein Problem. Jugendliche sind besonders davon betroffen.

Informationen und Hilfestellungen gibt es z.B. hier:

Mehr Datenschutz beim Yourpart-Etherpad

Das Etherpad unter www.yourpart.eu ermöglicht unkompliziert ein gleichzeitiges Arbeiten an Texten selbst über Distanzen hinweg. Nach einem Serverwechsel können wir den Dienst nicht nur zuverlässiger anbieten, sondern nun auch Datenschutz und die Wahrung der Privatsphäre der Nutzer*innen verbessern.

Ab sofort sind alle Verbindungen zum Etherpad-Server unter yourpart.eu automatisch verschlüsselt. Texteingaben können also auch beim Arbeiten in öffentlichen WLANs nicht von Dritten mitgelesen werden.

Screenshot

Beim Anlegen eines Pads lässt sich ein automatisches Löschen nach 30 Tagen Inaktivität eintragen (Screenshot: yourpart.eu)

Spannend ist auch die Neuerung, dass man beim Neuanlegen von Pads auswählen kann, ob das Pad nach 30 Tagen Inaktivität automatisch gelöscht werden soll: Veraltete Texte sind also nicht mehr automatisch für immer öffentlich abrufbar. Nutzer*innen haben damit künftig die Wahl, ob sie nur kurzfristig mit einem Pad arbeiten oder langfristig Inhalte zur Verfügung stellen wollen. Bestehende Pads werden durch diese neue Option natürlich nicht verändert.

Wir glauben, dass wir mit diesen beiden Verbesserungen eine Brücke zwischen dem offenen Ansatz von Etherpads und zugleich dem Wunsch nach einem gewissen Datenschutzniveau schlagen konnten.

In eigener Sache: tooldoku.dbjr.de ab sofort automatisch verschlüsselt

Seit heute ist für den Tooldoku-Blog ein Verschlüsselungszertifikat installiert. Bei Aufruf von tooldoku.dbjr.de werdet ihr automatisch auf die verschlüsselte Site https://tooldoku.dbjr.de weitergeleitet. Damit sind das Surfen auf unserer Dokumentations-Website sowie vor allem der Download des ePartool-Installers besser vor Eingriffen geschützt.

Überlegungen zu alten Nutzeraccounts – wie damit umgehen?

Wenn das ePartool über eine längere Zeit bei euch in Betrieb ist und bereits mehrere Beteiligungsrunden darüber durchgeführt wurden, wird sich irgendwann ein Problem stellen: Wie geht man mit veralteten Nutzeraccounts um? Wie werden Nutzer_innen gelöscht, die sich nicht mehr ins ePartool einloggen wollen oder sollen?

Durch ihre aktive Beteiligung hinterlassen Nutzer_innen im ePartool unweigerlich ihre Spuren: Beiträge in Beteiligungsrunden, Diskussionsbeiträge, Abstimmungsberechtigungen oder sogar Gruppenverantwortlichkeiten.

Dem Entfernen von Nutzer_innen aus dem System gehen konzeptionelle Fragen voraus, die gelöst werden müssen:

  • Es ist zu entscheiden, ob Beiträge von nicht mehr existierenden Nutzer_innen, anonymisiert oder ebenfalls gelöscht werden.
  • Bei tatsächlicher Löschung von Inhalten läuft man Gefahr, dass Beteiligungsrunden im Nachhinein verfälscht werden, da Beiträge oder Gruppen im System nicht mehr vorhanden sind. Die Auswirkungen sind weitreichend: Die zuvor festgestellte Anzahl der Teilnehmenden und Beiträge verändert sich, wertvolle Inhalte können verloren gehen. Gruppenabstimmungen müssten aus dem System herausgerechnet werden. Reaktionen zu Beiträgen und Diskussionen über Beiträge hätten keinen Bezugspunkt mehr.
  • Wenn man sich als Alternative für eine durchgehende Anonymisierung entscheidet, würden Diskussionsabläufe nicht mehr nachvollziehbar, da nun unterschiedliche Diskutant_innen als dieselbe „anonyme Person“ dargestellt würden. Auch statistische Auswertungen in Beteiligungsrunden könnten durch eine vollständige Anonymisierung im Nachhinein verfälscht werden.

Derzeit können im ePartool nur Nutzer_innen gelöscht werden, die selbst an keiner Beteiligungsrunde mit Beiträgen teilgenommen haben. Anders sieht es mit Nutzer_innen aus, die sich aktiv beteiligt haben oder an Abstimmungen teilgenommen haben. Hier möchten wir eine bessere Möglichkeit schaffen.

Folgende Funktionalitäten sollen ins ePartool neu integriert werden:

Anonymous Face by chatard | openclipart.org

Anonymous Face by chatard | openclipart.org

  • Beiträge werden von Gruppeninformationen getrennt und können nicht mehr zugeordnet werden (ähnlich wie bereits jetzt die von Anfang an anonym übermittelten Beiträge).
  • Abgeschlossene Absimmungen sollen endgültig anonymisiert werden, indem nur noch die Endergebnisse, nicht aber gehashte Stimmabgaben oder Teilnehmende weiterhin gespeichert werden.
  • Diskussionsabläufe bleiben mit Pseudonym erhalten oder bekommen durchnummerierte „Anonymous 1, 2, 3“-Urheber_innen.
  • Nutzeraccounts können stillgelegt werden, so dass sie auch im Administrationsbereich nicht mehr sichtbar erscheinen.

Gerne erfahren wir auch eure Gedanken und Ideen hierzu!

Automatisch auf Verschlüsselung umschalten – so geht’s

Ob man Websites verschlüsselt oder unverschlüsselt betrachtet, ist für viele Nutzer_innen nicht im Zentrum des Interesses: Man legt einfach los mit „www….“ oder kommt eh über eine Suchmaschine auf die Seiten. Professionelle Websites wie Banken oder Online-Shops leiten die Nutzer_innen zudem mittlerweile automatisch auf verschlüsselte https-Verbindungen weiter, wenn vertrauliche Daten wie Kennwörter oder Bankdaten übertragen werden sollen.

Generell spricht eigentlich nichts dagegen, die Verbindungen von Anfang an automatisch verschlüsselt laufen zu lassen. Und das automatische Umschalten zwischen unverschlüsselter und verschlüsselter Verbindung ist nicht schwierig zu machen – vorausgesetzt ihr verfügt bereits über ein SSL-Zertifikat bei eurem Provider.

Im Hauptverzeichnis eurer Website, also z.B. des ePartools, liegt eine sogenannte .htaccess-Datei. Diese Datei kann zentrale Einstellungen für alle Unterverzeichnisse vorgeben, also z.B. was passiert wenn Seiten nicht gefunden werden. Auch kann man hier Verbindungen automatisch von unverschlüsselt auf verschlüsselt weiterleiten.

Falls die Datei noch nicht existiert, dann legt einfach eine Textdatei mit Namen .htaccess an (ohne .txt-Endung!).

Die einfachste Version zum Umleiten auf die Verschlüsselung lautet:

RewriteEngine On

RewriteCond %{SERVER_PORT}   !^443$
RewriteRule  (.*)  https://%{HTTP_HOST}/$1   [L]

Was passiert da? Die erste Zeile sagt dem Server, dass er die aufgerufenen Seiten nach den folgenden Befehlen umleiten soll. Die „RewriteCond“ beschreibt die Bedingung, wann die folgende Regel zum Tragen kommen soll – also die „RewriteRule“. !^443$ bedeutet dabei nichts Anderes als dass die Verbindung anders als verschlüsselt angefragt wurde – und (.*) bedeutet, dass es alle Arten von Anfragen betrifft. Das [L] am Ende bedeutet, dass die Umleitungsregel hier ebenfalls zu Ende ist.

Die obige Regel funktioniert gut, wenn ihr das ePartool oder eure Website in einer eigenen Domain betreibt. Falls ihr aber nur ein Unterverzeichnis benutzen könnt und zudem unbedingt ein „www.“ am Anfang benötigt (z.B. weil das Zertifikat so ausgestellt ist), dann geht das über folgende Befehle. Statt unterverzeichnis müsst ihr natürlich den richtigen Namen des Unterverzeichnisses eintragen:

RewriteEngine On

RewriteCond %{HTTP_HOST}     !^www\.
RewriteRule (.*)             https://www.%{HTTP_HOST}/unterverzeichnis/$1 [L]

RewriteCond %{SERVER_PORT}   !^443$
RewriteRule (.*)             https://%{HTTP_HOST}/unterverzeichnis/$1 [L]

Ihr wollt es ausprobieren? Klickt auf http://www.dbjr.de – und schon werdet ihr weitergeleitet auf die verschlüsselte https-Verbindung.