Vielsprachige Beteiligung mit digitalen Tools

Schon gewusst? Unsere Beteiligungswerkzeuge stehen nicht nur in deutscher Sprache zur Verfügung, sondern können auch in einem internationalen Kontext hinaus verwendet werden.

Unser Server zum Organisieren und Durchführen von Barcamps und ähnlichen Seminaren, www.barcamptools.eu, steht für die Nutzer*innen auf Deutsch und Englisch zur Verfügung. Die bereits angelegte russische Übersetzung wird derzeit überarbeitet und geht im Frühjahr wieder online.

Das ePartool kann während der Installation und später über die Administrationsoberfläche in andere Sprachen umgeschaltet werden: Neben Deutsch sind Lokalisierungen in mehrere Sprachen vorbereitet, nämlich Englisch, Französisch, Polnisch, Tschechisch, Russisch und eine arabische Vorabversion. Die Übersetzungen sind noch nicht alle vollständig, aber wir arbeiten kontinuierlich daran. Es ändern sich dabei natürlich nicht die (selbst eingestellten) Inhalte der Beteiligungsrunden, aber alle Buttons, Labels und Systemnachrichten.

Antragsgrün wiederum steht auf Deutsch, Englisch und Französisch zur Verfügung. Unter motion.tools (Englisch) und sandbox.motion.tools/createsite?language=fr (Französisch) kann man sich davon einen ersten Eindruck machen.

Antragsgrün wird im Zusammenspiel mit Übersetzungsdiensten wie Google Translate richtig stark: Auf der DBJR-Vollversammlung konnten die internationalen Gäste stärker als bisher an der Versammlung partizipieren – dank einer automatisierten, stets aktuellen englischen und französischen Übersetzung aller Diskussionspapiere und -stände. Wie das funktionierte, kann man sich nachträglich noch ansehen: www.dbjr.de/antrag/web/vv2017.

Mit den meisten Übersetzungen kann unser Etherpad-Server yourpart.eu aufwarten, allerdings braucht man die übersetzten Labels eigentlich nur, um Spezialeinstellungen und Exportfunktionen zu verstehen.

Das Übersetzen unserer Tools ist eine laufende Aufgabe. Hier sind wir auch auf eure Unterstützung angewiesen! Wer Interesse hat, die Tools in weitere Sprachen zu übertragen oder uns dabei unterstützen möchte, bestehende Lokalisierungen für alle Nutzer*innen zu verbessern, nimmt gerne jederzeit Kontakt mit uns auf: digital@dbjr.de.

Tool-Tipp: Emojis auch auf dem Desktop-PC benutzen ?

Aus der digitalen Kommunikation sind sie heutzutage kaum mehr wegzudenken: Die »Emojis«. Was vor einigen Jahren noch recht rudimentär mit dem Smiley-Emoticon 🙂 begann, hat sich, beflügelt durch mobile Messenger-Dienste, beinahe explosionsartig weiter entwickelt. Und der aus dem Japanisch stammende Ausdruck »Emoji« für „Bildschriftzeichen“ ist mittlerweile schon fast Allgemeingut.

Um so ärgerlicher ist die Kommunikationsbarriere zwischen Smartphones und Desktop-PC oder Notebooks: Die Eingabe von Emojis ist bei Letzteren sehr viel komplizierter als auf dem Smartphone. Gegen eine reine Eingabe über die Tastatur spricht, dass mittlerweile viel zu viele Emojis existieren und dass das System seit der Einführung von geschlechterspezifischen und hautfarbe-wiederspiegelnden Zeichen noch deutlich komplexer wurde. In manchen Programmen oder Onlinediensten können Emojis eingefügt werden durch führende und schließende Doppelpunkte und dem entsprechenden Titel dazwischen. Aber auch das ist zu kompliziert, wenn sich man Beispiele wie :heart_eyes: für ? oder :stuck_out_tongue_winking_eye: für ? merken soll.

Zum Glück ist Hilfe nah: Kleine Programme, die das Auffinden und Verwenden der richtigen Emojis deutlich erleichtern. Eines dieser Helferlein wollen wir heute vorstellen: Der frei verfügbare Emoji-Helper »Emoji Cheatsheet«. Als kleines Add-on kann es in den verschiedenen Browsern (Mozilla Firefox, Google Chrome, Opera und Apple Safari) installiert werden oder ganz neutral als sogenanntes „Bookmarklet“ genutzt werden. Künftig findet man die gesuchten Zeichen ganz bequem dank der Übersicht, die man aus Messenger-Diensten kennt. Per Copy & Paste kann das gewünschte Emoji dann herauskopiert und an beliebiger Stelle im Browser oder auch in anderen Programmen eingefügt werden.

Der Emoji-Helper »Emoji Cheatsheet« wird offen auf Github entwickelt und kann frei heruntergeladen und verwendet werden. Weitere Infos unter http://johannh.me/emoji-helper/

Tool-Tipp: Mit »DeepL Translator« gut verständlich übersetzen

Zwar ist es schon eine Weile her, als automatische Übersetzungsdienste „Bill Clinton“ noch falsch als „Rechnung Clinton“ ins Deutsche übertrugen, von Perfektion sind die bekannten Übersetzer von Google und Microsoft Bing trotzdem noch weit entfernt.

Das neue Angebot des in Deutschland beheimateten Unternehmens DeepL, das auch das bekannte Onlinewörterbuch Linguee betreibt, setzt nun auf neuronale Netzwerke und bietet einen komfortablen und sehr hochwertigen, automatischen Übersetzungsdienst an: Der kostenlose »DeepL Translator« ist erreichbar unter https://www.deepl.com/translator.

Unsere stichprobenartigen Tests ergaben, dass auch Texte mit Jugendarbeitsbezug gut lesbar in verschiedene Sprachen übertragen wurden. Sicherlich ist die automatische Übersetzung noch deutlich von einer muttersprachlichen Übersetzung zu unterscheiden, allerdings blieben die geprüften Textbeispiele im Gegensatz zu anderen Diensten gut verständlich. Falsch übersetzte Begriffe stellen bei DeepL ebenfalls kein Problem dar: Einfach auf ein falsch übersetztes Wort klicken und schon erhält man vom System mehrere Alternativvorschläge zur Auswahl.

Datenschutz: Wie bei allen kostenlos zur Verfügung stehenden Diensten im Netz muss man sich bewusst sein, dass die übertragenen Daten (also eure Texte) auf einem euch nicht bekannten Server verarbeitet und dort gespeichert werden können.

Bisher sind die Sprachen Deutsch, Englisch, Französisch, Italienisch, Niederländisch, Polnisch und Spanisch verfügbar. Im Zweifelsfall muss die Ausgangssprache nicht ausgewählt werden, sondern wird automatisch erkannt. Als weitere Sprachen angekündigt sind bereits Portugiesisch, Russisch, Japanisch und Mandarin.

Lesetipp: Gebärdensprache – Lautlos in der IT-Welt

Im IT-Bereich werden mit neuen Entwicklungen auch ständig neue Wörter eingeführt. Manche finden schnell ihren Weg in den allgemeinen Wortschatz – aber wie werden eigentlich diese Begriffe in Gebärdensprache ausgedrückt? Das Nachrichtenportal Golem.de hat einen sehr interessanten Artikel darüber veröffentlicht, wie Gehörlose mit den zahlreichen Abkürzungen und Anglizismen der IT-Welt in Gebärdensprache umgehen, auf welche Probleme sie stoßen und welche Lösungen es gibt.

https://www.golem.de/news/gebaerdensprache-lautlos-in-der-it-welt-1708-129151.html

Tool-Tipp: Große Dateien versenden mit send.firefox.com

Kurz mal einen Videoclip vom letzten Projektwochenende verschicken oder Druckvorlagen an eine Agentur schicken? E-Mail eignet sich leider für große Dateien nicht, so dass oft der Weg über Clouddienste wie Dropbox oder Google Drive gewählt wird. Diese Dienste sind allerdings nicht nur datenschutztechnisch umstritten (siehe z.B. hier und hier), auch setzen sie stets auch einen festen Nutzeraccount voraus.
Die gemeinnützige Mozilla-Stiftung, die allgemein vor allem durch Entwicklung des Firefox-Browsers und Thunderbird-Mailprogramms bekannt ist, bietet im Rahmen ihrer „Experiments“ einen neuen Dienst im Testbetrieb an: Dateien bis 1 GB Größe können ohne vorherige Anmeldung direkt übers Netz verschickt werden.

Dazu begibt man sich auf send.firefox.com, schiebt per Drag & Drop die zu versendende Datei in den Browser und und erhält einen bis zu 24 Stunden lang gültigen Link, der nur noch an den/die Empfänger_in weitergeleitet werden muss. Danach werden die Dateien wieder automatisch gelöscht.

Screenshot send.firefox.com

Die übersichtliche Seite send.firefox.com ist auch auf Deutsch verfügbar

Datenschutz: Die Dateien werden auf Servern der Mozilla-Stiftung bis zum Abruf durch den/die Empfänger_in zwischengespeichert. Theoretisch könnte die Stiftung oder Andere, die euren Link unbefugt erhalten, auf die Dateien zugreifen. Um die zu versendende Datei zusätzlich abzusichern, kann man sie vor dem Upload z.B. über ein populäres, sicheres Packprogramm wie 7zip in ein passwortgeschütztes ZIP oder 7z-Archiv packen. Das Vorgehen über ein ZIP-Paket bietet sich auch an, wenn ihr auf einen Schwung viele Dateien (z.B. Fotos) versenden wollt.

Keine Datenschutzbedenken mehr: Selbst einen Send-Server betreiben

Die zugrundeliegende Software entwickelt Mozilla als Open-Source-Tool. Die Entwicklung erfolgt offen zugänglich über Github (https://github.com/mozilla/send). Dort findet sich auch eine Erklärung, wie man selbst einen Send-Server aufbauen und für eigene Bedarfe in einem Projekt oder der eigenen Organisation betreiben kann.

In eigener Sache: Tooldoku übersichtlicher

Regelmäßige Besucher_innen werden es schon bemerkt haben: Wir haben in den letzten Tagen an einigen Stellen der Tooldoku-Website geschraubt.

Screenshot neuer Tooldoku-KopfbereichDer Tooldoku-Blog war vor einigen Jahren gestartet worden, um die Entwicklung des ePartool zu begleiten und zu dokumentieren. Mittlerweile sind weitere Tools hinzu gekommen und die Entwicklung selbst findet nun dank des Gemeinschaftsprojekts jugend.beteiligen.jetzt in einem stabileren Rahmen statt.

Um dieser Entwicklung Rechnung zu tragen, haben wir sowohl den Blog wie auch die weiteren Seiten etwas umstrukturiert und das Hauptmenü entschlackt. Damit die neuesten Blogbeiträge zu genau dem Tool, für das man sich gerade interessiert, schneller findet, gibt es nun für den Blog rechts eine Auswahlmöglichkeit »THEMEN & KATEGORIEN«.

Und nicht zuletzt haben wir auch den technischen Stand aktualisiert: Die Tooldoku-Website läuft nun auf PHP 7.

Fremde Inhalte einbinden und trotzdem „sicher“ bleiben?

Das Besondere am World Wide Web ist, dass alle Inhalte miteinander vernetzt sein können. Mit nur einem Klick gelangt man zu weiterführenden Informationen oder neuen Inhalten. Zugleich wurde auch das traditionelle Konzept von „Seiten“ durch das WWW dank seiner Vernetzungs- und Interaktionsmöglichkeiten deutlich erweitert. Neben Fließtext und Bildern kann eine Seite aus weiteren Elementen bestehen, die aus ganz unterschiedlichen Quellen interaktiv eingebunden sind: Youtube-Videos, aktuelle Podcasts, Instagram-Fotos, Tweets (Twitter) oder Präsentationen mit Prezi sind nur ein paar der bekannteren Beispiele.

Diese Einbinde-Möglichkeit hat aber auch ihre Kehrseite, da man selbst als Seitenbetreiber_in kaum mehr überblicken kann, was am Ende auf einer Seite zu sehen sein wird. Thematisch unpassende, aufdringliche Werbeanzeigen nerven; Tracking-Cookies von Werbetreibenden oder von Social Media Funktionen durchleuchten die Besucher_innen meist ohne Vorwarnung und ohne Opt-out-Möglichkeit.

Über solche unerwünschte Aspekte hinaus bedeutet die vernetzte Herangehensweise des World Wide Web auch, dass sogar gefährliche Inhalte in eigentlich harmlose Seiten hineingeraten können.

Typische Einfallstore

Die Einfallstore sind zum Einen die eigentlich willentlich eingebundenen externen Quellen und zum Anderen (unbewusst) bestehende Sicherheitslücken: Wenn die eigene Website durch ein Content Management System befüllt wird, finden sich trotz aller Sorgfalt immer wieder Schwachstellen in der Programmierung dieses Redaktionssystems. Gerade interaktive Funktionalitäten sind besonders gefährdet. Typische Beispiele sind hierfür

  • Formulare (Anmeldemasken, Registrierungsformulare, Fragebögen, Suchfelder), die die eingegebenen Daten nicht auf den eigentlich beabsichtigten Inhalt prüfen oder beschränken, sondern z.B. statt der Eingabe einer eMail-Adresse dann möglicherweise die Übertragung von Programmiercode erlauben;
  • Funktionen zum Hochladen von Dateien (im Kern ebenfalls Formulare), die es versäumen zu überprüfen, ob z.B. wirklich nur eine Grafik oder doch stattdessen Programmcode übertragen wurde;
  • Suchfilter oder andere Parameter, die von einer Seite an die nächste übergeben wurden und bei denen aufgrund mangelnder Überprüfung Code-Einschleusung nicht verhindert wurde.

Eine so präparierte Website kann dadurch ganz andere Inhalte anzeigen als ursprünglich beabsichtigt. Wenn Nutzer_innen dann per eMail oder über Social-Media eine Einladung erhalten die Seiten zu besuchen, können sie nur sehr schwer erkennen, dass die Inhalte manipuliert wurden. Die Web-Adresse sieht ja weiterhin vertrauenswürdig aus und selbst die möglicherweise vorhandene https-Verschlüsselung funktioniert wie eh und je.

Die Lösung naht: Fremde Quellen explizit durch CSP freigeben

Um diesem Dilemma etwas entgegenzusetzen, wurde das Konzept der »Content Security Policy« (CSP) ersonnen. Im Kern funktioniert es so, dass die Betreiber einer Website im Rahmen einer Liste (Whitelist) einzeln aufführt, von welchen fremden Quellen Inhalte überhaupt auf der Website erscheinen dürfen. Die Liste ist dabei in einzelne Sektionen unterteilt. So kann beispielsweise festgelegt werden, dass für Audio und Video bestimmte Quellen zugelassen sind, Schriftarten oder eingebundene Fragebogen aber wiederum nur von anderen Quellen. Dadurch soll verhindert werden, dass eingebunde Quellen Inhalte mit ausliefern, die man als Betreiber_in einer Website nicht vorher eingeplant hat.
Dieses „Whitelisting“ hat allerdings eine Kehrseite: Nicht explizit freigegebene Quellen werden auch ohne weitere Erklärung unterdrückt. Wenn man beim Befüllen der Inhalte die Liste der Freigaben nicht im Kopf hat, wird man bei nicht-angezeigten Inhalten kaum die Ursache des Problems erkennen. Eine Einführung von CSP-Mechanismen sollte daher immer in enger Abstimmung zwischen den technisch und den redaktionell verantwortlichen Teams erfolgen.

Umsetzung von Content Security Policy im ePartool

Das ePartool unterstützt seit dem Frühjahr 2017, ab den Versionen 4.3.x, das Konzept der Content-Security-Policy.

Seither haben wir die Konfiguration noch etwas vereinheitlicht und verbessert. Die Quellen können in der Datei config.ini des ePartool eingetragen werden. Aus Sicherheitserwägungen heraus kann die Liste leider nicht bequem über die Redaktionsoberfläche verändert werden (da sie sonst angreifbar wäre und der Sicherheitsaspekt konterkariert würde). Wir liefern das ePartool bereits mit häufig benutzen Quellen aus, allerdings lohnt es sich auf jeden Fall, die Liste selbst noch zu überprüfen.

Der Aufbau und eine Übersicht der vorhandenen Einstellungsmöglichkeiten finden sich in der config.ini-Beispieldatei, die im selben Ordner zu finden ist wie die config.ini selbst: tool/application/configs/config.local-example.ini

; CORS settings - contains list of allowed addresses from where can be loaded external resources
; allow address for specific type of resource
; for details see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

; Serves as a fallback for the other fetch directives
; cors.default-src[] = "*.example.com"

; Specifies valid sources of application manifest files - <link rel=manifest>
; cors.manifest-src[] = "*.example.com"

; Specifies valid sources for loading media using the <audio> and <video> elements - <video> <audio> <source> <track>
; cors.media-src[] = "*.example.com"

; Specifies valid sources for the <object>, <embed>, and <applet> elements
; cors.object-src[] = "*.example.com"

; Restricts the URLs which can be used as the target of a form submissions from a given context
; cors.form-action[] = "*.example.com"

; Specifies valid sources of images and favicons
; cors.img-src[] = "data: *.example.com"

; Specifies valid sources for fonts loaded using @font-face
; cors.font-src[] = "*.example.com"

; Specifies valid sources for JavaScript
; cors.script-src[] = "*.example.com"

; Specifies valid sources for stylesheets - <link rel=stylesheet>
; cors.style-src[] = "*.example.com"

; Restricts the URLs which can be loaded using script interfaces - XmlHttpRequest() WebSocket() EventSource() sendBeacon() fetch()
; cors.connect-src[] = "example.com"

; Defines the valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>
; cors.child-src[] = "*.example.com"

 

Browserunterstützung: Fast alle sind dabei

CSP wurde bereits weiter entwickelt und ist derzeit in der zweiten Ausbaustufe technisch definiert. Während die Grundfunktionen mittlerweile in den meisten Browsern Einzug gefunden haben, wird der aktuelle Level 2 des Content Security Policy Konzepts vom Opera Mini und dem Internet Explorer 11 nicht unterstützt (aber vom Microsoft-Edge-Browser). Detaillierte Informationen hierzu finden sich bei »Can I Use …« unter https://caniuse.com/#search=csp

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.

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.

Digitale Tools und Mehrsprachigkeit – ePartool

Das ePartool ist ursprünglich für die deutsche Umsetzung des europäischen Strukturierten Dialogs mit der Jugend entwickelt worden. Allerdings gab es bereits vor drei Jahren mehrere Gespräche mit der EU-Kommission, da sie Ideen und Teile des ePartools für europäische Konsultationen übernehmen wollten. Auch aus diesem Grund begannen wir damit, das ePartool besser darauf vorzubereiten, dass es auch in mehrsprachigen Szenarien eingesetzt werden kann.

Kern einer Internationalisierung bzw. Lokalisierung für verschiedene Sprachen sind Sprachdateien. Das bedeutet, dass einzelne Meldungen des Systems, Buttons, Beschriftungen usw. nicht direkt im Quelltext der Programmierung zu finden sind, sondern über Platzhalter die jeweils ausgewählte Sprachversion „eingestempelt“ wird. Zur Übersetzung muss später also nur die einzelne Sprachdatei überarbeitet und nicht die gesamte Programmierung durchsucht werden.

Screenshot Testversion Tschechisch

Bei Mehrsprachigkeit müssen auch die verfügbaren Schriften alle notwendigen Zeichen abdecken, sonst sieht’s schnell komisch aus.

Derzeit wird das ePartool in mehrere Sprachen übersetzt: Neben der bestehenden deutschen und englischen Version sind Übersetzungen ins Französische, Spanische, Polnisch, Tschechische, Russische und sogar ins Arabische bereits recht weit fortgeschritten. Wie immer liegt der Teufel im Detail.

  • Die Konzepte hinter den verschiedenen Begriffen im ePartool müssen für die Übersetzenden nachvollziehbar sein. Und dann müssen sie noch einen guten Begriff in ihrer Zielsprache finden. Hier sind auch die späteren Nutzergruppen zu berücksichtigen. Solche Fragen müssen wir uns auch in der deutschen Entwicklung immer wieder stellen: Ist „Konsultation“ ein guter Ausdruck oder wäre „Beteiligungsrunde“ besser zu verstehen?
  • Sprachen benötigen eine unterschiedliche Anzahl von Buchstaben, um Dinge auszudrücken. Reicht hierfür stets der Platz?
  • Was ist in der jeweiligen Sprache üblich: Werden die Nutzer*innen direkt angesprochen oder formuliert man Systemmeldungen eher in der dritten Person?
    – Die Darstellung von Datum und Uhrzeitangaben oder Zahlen (Tausender/Dezimalstellen) sind sehr unterschiedlich.
  • Screenshot Testversion Russisch

    Manche Sprachen benötigen mehr Buchstaben als andere.

  • Welche Auswirkungen haben Übersetzungen auf die Gestaltung das „Graphical User Interface“ (Nutzeroberfläche)? Gerade wenn man wie im Arabischen von rechts nach links schreibt, sind auf europäische Sprachen ausgerichtete Pfeile und Grafiksymbole möglicherweise gar nicht mehr passend.
  • Überlegt werden muss auch, wie weit die Mehrsprachigkeit gehen soll: Ist der bestehende Sprachumschalter im Adminbereich ausreichend oder sollen Nutzer*innen selbst die Sprache für sich umschalten können? Was passiert mit den Inhalten, die nur einsprachig verfügbar sind?

Wir widmen uns Stück diesen Aufgaben, damit das ePartool und bald auch die anderen Tools in vielen Sprachen nutzbar werden. Wenn ihr uns bei der Übertragung in weitere Sprachen unterstützen wollt, sprecht uns gerne an!