Follow

Aus gegebenem Anlass: ist zwar ein -Dienst (weil Dokumente nur -verschlüsselt gespeichert werden), aber wenn man ihn hinter einem Webserver betreibt, der wie die IP-Adresse loggt, sind die Nutzenden nicht wirklich anonym.

Bekanntlich sagte der frühere NSA- und CIA-Direktor Michael Hayden: “We kill people based on metadata”

Wir haben eben nochmal nachgesehen, um sicher zu gehen, dass cryptpad.digitalcourage.de keine schreibt. In /etc/nginx/nginx.conf steht deshalb folgendes:

http {

access_log /dev/null;
error_log /dev/null;

}

Bei digitalcourage.social und nuudel.digitalcourage.de ist das genauso konfiguriert.

Damit sind unsere User auf der sicheren Seite.

/c

@digitalcourage Laut GDPR muss der Webserver doch eh so eingestellt sein, dass die IPs nicht Personen zugeordnet werden können, oder?

@ArneBab

Das ist aber bei den üblichen Webservern immer noch nicht die Voreinstellung, obwohl es dafür anno 2000 einen der ersten gab und die auch vorschreibt.

bigbrotherawards.de/2000/sonde

/c

@ArneBab Daher suche ich (zugegeben nicht sehr intensiv) seit Jahren #Apache- und #nginx-Entwickler, um diese IP- Anonymisierung in der Kern zu bringen.
nerdculture.de/@kirschwipfel/1
@digitalcourage

@ArneBab Oh, das Modul gibt es bereit für Apache?! Sehr schön, sehr schön. Muss es nur noch default werden. Und nginx braucht auch eines. @digitalcourage

@kirschwipfel @digitalcourage Im Leitfaden steht nginx auch — das brauchte nur eine bessere default config.

@ArneBab @jakob @digitalcourage @kirschwipfel ich hab die access.log einfach ganz abgeschaltet, wüsste eh nicht wofür ich die brauche.

@Tealk In Firmen will das Marketing of Auswertungen der Logs. Wenn sie dafür eigen Logs verwenden und nicht GoogleAnalytics haben wolle, ist das ja schon ein riesiger Fortschritt. Als Admin musst Du dann Logs bereitstellen — die müssen natürlich anonymisiert sein.@ArneBab @jakob @digitalcourage

@digitalcourage Das ist nicht die Voreinstellung? … yikes!

dryads-wake.1w6.org/ hat jetzt GDPR-konformes Logging …

Danke für die Warnung!

@ArneBab @digitalcourage Ob die Betreiber IPs depseudonymisieren können, ist nach meinem Verständnis weniger das Problem. IPs sind prinzipiell zuordenbar. Deshalb sollten sie am besten gar nicht erst gespeichert werden.

@mupan @digitalcourage Die Einstellungen sollten sein, dass bei IPv4 die letzten zwei Bytes und bei IPv6 alle bis auf die ersten vier Bytes nullgesetzt werden.

Sind auch die beiden ersten Bytes schon gefährlich?

@ArneBab @digitalcourage Ich vermute nicht, denn die Adressbereiche lassen ja wohl nur Rückschlüsse auf große Unternehmen wie Provider zu. Wenn aber der Nutzen für die Fehlersuche bei Internet-Conumer-Clients bei ganzen IPs schon fraglich ist, was will ich denn mit Adressbereichen? Sind so viele Fehler providerabhängig?

@mupan @digitalcourage Über die Addressbereiche findest du zum Beispiel heraus, aus welchem Land die meisten der Webseitenbesucher kommen.

@mupan @digitalcourage Und Providerabhängig ist z.B., ob deine Seite auf einer Blackliste gelandet ist. „warum gibt es plötzlich keine Anfragen mehr aus dem Bereich?“

@ArneBab @digitalcourage Überzeugt mich nicht, dass das Debuggingpotential so überwältigend wäre, dass es die Schutzpflicht überwiegen würde.

@mupan @ArneBab

Genau. Zur Fehlersuche kann man das Logging kurzzeitig deaktivieren. Aber diese versteckte per Default muss aufhören. /c

@digitalcourage @mupan Da eine IP mit nur den ersten beiden Feldern nicht auf Personen zurückgeführt werden kann, gibt es dafür keine Schutzpflicht.

Ich nutze die (bei meinem File+DB-Hosting Provider anonymisierten Logs) z.B. um zu schauen, aus welchen Ländern Leute die Seite besuchen.

Wobei mir erst jetzt aufgefallen ist, woher die Diskrepanz zwischen „Visitor“ und „Access“ bei Dateien in den Logs kommt: 1.2.3.4 1.2.200.180 und 1.2.4.3 sind anonymisiert alle die gleiche IP.

@mupan Da hast Du recht: Für Debugging genügt es, wenn es keine Logs gibt und der/die Admin sie bei Bedarf kurzzeitig anschaltet.
Allerdings will in Firmen das Marketing oft Auswertungen der Logs. Wenn sie dafür eigen Logs verwenden und nicht GoogleAnalytics haben wolle, ist das ja schon ein riesiger Fortschritt. Als Admin musst Du dann Logs bereitstellen — die müssen natürlich anonymisiert sein.
@ArneBab @digitalcourage

@kirschwipfel @ArneBab @digitalcourage Schutzpflicht bestehe wegen Nicht-Personenbeziehbarkeit nicht, sagt Arne. Mag sein. Das wäre zu prüfen, Herkunftsland und Provider sind kombiniert mit anderen Informationen oft sprechender, als auf den ersten Blick angenommen. Millisekundengenaue Zeitstempel stellen Verbindungen her.

Auswertungen fürs Marketing müssen m.E. gegen den Datensparsamkeitsgrundsatz geprüft werden. Dass es auch schlimmer geht, ist für mich kein Argument.

@mupan Drehen wir uns gerade im Kreis, oder auf was beziehst Du dich? IP-Adressen sind personenbezogene Daten, das ist schon lange gerichtlich bestätigt. Darum ja anonymisierten. @ArneBab @digitalcourage

@kirschwipfel @mupan @ArneBab @digitalcourage

Mupan weist zurecht darauf hin, durch das Kürzen von IP-Adressen ein Deanonymisieren der User nicht völlig ausgeschlossen ist, wenn man weitere Informationen hinzunimmt. In typischen Webserver-Logfiles findet man ja z.B. auch die Browser-Version und genaue Zeitstempel. Also am besten gar nichts loggen.

Aber natürlich ist interne Logfile-Analyse weniger schlimm als das Ausleiten von personenbezogenen Daten via Tracker zu Google Analytics & Co.

@chpietsch Und zusätzlich frage ich mich, warum jemensch z.B. auswerten will, aus welchem Land und über welche Provider auf ihre Seiten zugegriffen wird. Ich weiß, die wenigsten bauen heutzutage statische Seiten, und es ist traurige Regel, dass viele Seiten ohne Javascript, Cookies und oft auch DOM-Speicher gar nicht mehr aufgehen und sich nicht navigieren lassen. @kirschwipfel @ArneBab @digitalcourage

@chpietsch Dann muss mich vorherrschende Technologie interessieren, wenn meine Seite lesbar bleiben soll. Es ist sicher aufwändiger, z.B. mit Hugo den dynamischen Prozess statt in den Userbrowser auf den Server, vor die Veröffentlichung zu legen. Und es bleiben Datenbankzugriffe nach Usereingaben usw., die mit statischen Seiten vermutlich nur schwer performant und im Design ansprechend beantwortet werden könnten. Jedenfalls wird Webdesign nicht so gelehrt, wie sowieso keine IT-Disziplin wirklich sauberes Design fördert.

Kurz: Die Personenbeziehbarkeit ist nur eine Frage, auch Fragen nach Zwecken, nach Datensparsamkeit, nach der Zugriffskontrolle und dem Datenzugriffskonzept (wer? wann? warum? wozu?) müssen sich alle ITler gefallen lassen. Dabei geht es nur um die grunsätzliche Missbrauchbarkeit. Ob der Wille zum Missbrauch beim aktuellen Personal vorhanden ist oder nicht, spielt im Datenschutz keine grundsätzliche Rolle.
@kirschwipfel @ArneBab @digitalcourage

@chpietsch Natürlich kann oder muss (noch) bei internem und technischem Logging und Monitoring freier damit umgegangen werden. Gerade da beruht immer (noch) viel auf Vertrauen.

Konkret hier weiß ich es schlicht nicht. Ich weiß bloß, welche Fragen ich als Datenschutzbeauftragter DSB oder Betriebsrat/Personalrat BR stellen würde. Und ich weiß, schon, weil ich selbst viel loggen und Daten korrelieren muss, dass es ziemlich selten so harmlos ist, wie es erscheint.

Technisch werden Prozesse von Data Access Layer von Nutzdaten immer besser getrennt, Testbetrieb immer besser vom produktiven, Domänen mit Reverse proxies gegen das Internet abgesichert, Windowsmaschinen lokal auf Linux virtualisiert und damit kontrolliert. Es ist eine Frage des Geldes, ob das bzw. wie viel davon umgesetzt wird. In dieser Welt kann schon mit normalen Mitteln viel zu viel mitgeschnitten werden.

@kirschwipfel @ArneBab @digitalcourage

@chpietsch Die DSB bei uns arbeiten, auch als externe, für den Unternehmer, nicht für die Öffentlichkeit und nicht für die Lohnabhängigen. BR sollten sich deshalb fortbilden, dass sie DSB und Unternehmer die richtigen Fragen stellen, auf Betriebsvereinbarungen pochen können, in denen Rollenkonzepte, erlaubte protokollierte Auswertungen und jederzeitige BR-Kontrolle festgeschrieben sind. Dazu muss es BR-Mitglieder oder Gewerkschaftsaktive geben, die verstehen, was das ist, bedeutet, und wie sie das Rollenkonzept und seine Umsetzung sowie die Auswertungslogs selbst prüfen. In vielen Landespersonalvertretungsgesetzen haben Personalräte PR die Pflicht, auf allgemeine Einhaltung der Gesetze in ihrer Dienststelle / ihrem Vertretungsbereich zu achten. Auch, wenn Auswertungen gar nicht die Lohnabhängigen, sondern z.B. die Öffentlichkeit betreffen, haben sie das Recht und die Pflicht zu hinterfragen und zu prüfen.
@kirschwipfel @ArneBab @digitalcourage

@mupan Warum das jemand auswerten will: ich schaue z.B. nach, woher Leute auf draketo.de/anderes/honest-mark kommen. Lohnt es sich, das in Deutschen Netzen zu veröffentlichen, oder klicken die Leute nur Deutsches? Was würde es vorraussichtlich bringen, einen bestimmten Text zu übersetzen? Der Text wurde z.B. aus UK, Finnland, Deutschland und Frankreich gelesen — in der Reihenfolge. Eine Deutsche Übersetzung könnte sich also lohnen (Finnisch kann ich nicht). @chpietsch @kirschwipfel @digitalcourage

@mupan ein wichtiges Ergebnis ist allerdings erstmal: 1/3tel der Besuche kommt vom Browser „Feeds“ — das ist Mastodon. @chpietsch @kirschwipfel @digitalcourage

@ArneBab @chpietsch @kirschwipfel @digitalcourage Ein reiner Klickzähler auf einen Deepl.com*-Link täte es aber hier auch. Eine maschinelle Übersetzung, die sehr oft geklickt wird, sollte von Übersetzer.inn.en geglättet werden.

* libretranslate.de, wenn deren Übersetzungen besser geworden sein werden.

@mupan Es gibt aktuell keine Übersetzung und auch keine zweite Seite. Vielmehr geht es ja um die Frage, ob sich sowas für den Artikel überhaupt lohnt — oder genauer: für welche Artikel es sich lohnt. Und dafür sind Serverlogs mit Lokalisierung nach Land sehr nützlich. Die Browser-Info braucht es dafür, um Bots zu erkennen (z.B. die 30% Mastodon-Instanzen bei dem Artikel). @chpietsch @kirschwipfel @digitalcourage

@mupan Würde das auch noch gelten, wenn die Zeitstempel nur stundengenau wären? Für die meisten legitimen Zwecke sollte das reichen. Für die Rückverfolgung von Angriffen könnte Minutengenaues Loggen allerdings nötig sein (für meine Zwecke aber nicht). @kirschwipfel @digitalcourage

@digitalcourage Rein aus Interesse: Warum /dev/null und nicht einfach "off" als Wert fürs Access-Log? 🙂

Hat das irgendwelche Vorteile, die ich noch nicht kenne oder wolltet ihr es nur einheitlich haben? Normalerweise hätte ich ja gesagt, dass /dev/null mehr Ressourcen benötigt, als es einfach zu deaktivieren.

@cs

Die Lösung mit /dev/null funktioniert mit allen Versionen von nginx. Die mit "off" nur in bestimmten (neueren). Schaut am besten in die Doku zu eurer Version. /c

@digitalcourage warum nicht einfach access_log off; bzw error_log off; ?

Sign in to participate in the conversation
digitalcourage.social

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!