Datenschutz auf dem Theorieblog

Seit zwei Jahren ist die europäische Datenschutzgrundverordnung (DSGVO) in Kraft. Am 25. Mai dieses Jahres, also morgen, endet die in der Verordnung vorgesehene Übergangszeit, ab diesem Tag kommen die Vorgaben der DSGVO europaweit zur Anwendung. Auch für einen Wissenschaftsblog wie den Theorieblog entstehen daraus gewisse Verpflichtungen. Insbesondere sind wir nun gesetzlich verpflichtet, eine umfassende Datenschutzerklärung zu veröffentlichen. Diese enthält u.a. Hinweise zur Datenerfassung im Rahmen unseres Email-Newsletters und ist unter dem folgenden Link abrufbar:

http://www.theorieblog.de/index.php/datenschutz/

Wie unserer Datenschutzerklärung zu entnehmen ist, ist es seit jeher unser Anliegen, den Theorieblog technisch so zu gestalten, dass so wenige personenbezogene Daten wie möglich erfasst werden. Interessanterweise setzt dies ein nicht geringes Maß an technischer Kenntnis und Aufmerksamkeit voraus. Über Anmerkungen und Vorschläge zu unserer Datenschutzerklärung freuen wir uns sehr. Bitte sendet uns dazu am besten eine Email an team@theorieblog.de.

10 Kommentare zu “Datenschutz auf dem Theorieblog

  1. In der Tat gibt es wohl kaum noch „dünnere“ Möglichkeiten einer WP-Installation hinsichtlich pers. Datenabdrücke, die Übermittlung (und Zusammenführung mit den Daten aus dem pers. Besuch anderer Seiten weit „dickerer“ Übermittlungsbreite) unserer Aufrufe hier an s0.wp.com (im referrer-header) und an google (Schriftarten/fonts-Ressource) sind wohl das Minimum innerhalb eines voraufgestellten WP-Rahmens, wie ihn hosteurope anbietet. (Als eigenes Server-Modul auf eig. Server könnte man den s0.wp.com-Durchstich vlt. mit viel Arbeit noch herausbohren, aber google hat tausende wichtiger Schriftarten aufgekauft/exklusiv an sich gezogen, so daß man auch wieder nur mit einiger bis sehr viel Arbeit diesen Anruf umgehen könnte).
    Ich denke, ich habe s0.wp.com gesperrt, die angeblich angeforderte devicepx-jetpack.js (mit ?ver=201821 im Parmeter) wird hier (PC) nicht gebraucht, um die Seiten gut anzuzeigen und zu interagieren.
    Der Keep-Alive-Header ermöglicht es der WP-Seite auch später von sich aus dieser Page/diesem Tab/Fenster noch etwas zu senden, solange es offen ist/seine window-Identität unverändert ist. Das können auch Skripte sein, die vorgesammelte, und von daher in der traffic-Schau noch nicht aufgefallene, Daten dann übertragen.
    Soweit mal ein erster Blick auf den Traffic der ersten 30 min. eines Besuchs mit Navigation, denn entscheidend ist, was „rübergeht“, dann erst kommen die Fragen nach den MÖGLICHKEITEN, die Third-Parties im Zusammenhang mit DS und unabhängiger, zuverlässiger Funktionalität so eingeräumt worden sind, und die im Falle des Falles dann eben zur inhaltlichen Filterung & Beinflussung bis zur Fälschung oder zum Funktionsverlust instrumentalisiert werden können.

    Ach ja, – noch von wegen „keine cookies“ (in der DS-Erklärung):
    Wer unten bei „Meinen Namen, E-Mail und Website in diesem Browser speichern, bis ich wieder kommentiere.“ das Häkchen setzt, und einen Kommentar abschickt, der/die generiert i. a. R. einen cookie, mit e-mail und ggfls. website-url in Klartext, der für die skriptberechtigten Dritten des Hauptfensters lesbar ist.

  2. Hier steht, wie sich WordPress-Betreiber/-Blogger die google-fonts-ABFRAGE schenken können:

    http://www.mittwald ***
    .de/blog/mittwald/howtos/ ***
    dem-datenschutz-zuliebe-wie-ihr-google-fonts-lokal-in-eure-webseiten-einbindet ***
    #Benoetigte-Google-Fonts-herunterladen ***

    Zeilenumbrüche und „***“ entfernen!, – die sind nur wegen der Link-Blockade beim Kommentieren drin …

  3. Lieber dos, danke für deine gründliche Auseinandersetzung mit unserem Setup und die sehr hilfreichen Hinweise. In der Tat ist es gar nicht so einfach, einen blog wie diesen konsequent datensparm zu betreiben. Aber ich denke, wie du ja auch schreibst, dass wir da schon auf einem ziemlich guten Weg sind. Zwei Punkte will ich mir aber auf jeden Fall zeitnah noch angucken:
    (1) Ob es eine Möglichkeit gibt, sich (und uns allen) die Google-Fonts-Abfrage zu ersparen.
    (2) Wie ich die Funktion bei den Kommentaren, Namen etc. zu speichern, rauskriege.

    Ich denke, die Link-Blockade in Kommentaren war durch Akismet Anti-Spam vorgegeben, Antispam-Bee scheint da etwas toleranter zu sein…

    Für weitere Hinweise bin ich dir sehr dankbar!

  4. Zu (2)
    Ja, da fehlt eine clientseitige event-Funktion, die die Änderung auf „nicht“ (das Häckchen kann man ja GRAFISCH wegnehmen) auch in den Textkörper/die Inhalte der Form, die zum Server geposted wird, abbildet.
    DAS GESCHIEHT HIER GAR NICHT, das Entfernen des Häkchen bleibt pure Kosmetik im grafischen/obersten layer des UI!
    Eine solche Funktion mit gut 90%iger Browserabdeckung (Einbindung eines Scriptes durch Euch) wäre wohl kein Problem, doch wäre zunächst zu prüfen, ob die „https://www.theorieblog.de/wp-comments-post.php“ (-> Ausführung zunächst auf dem Server, daher keine Einsicht in die serverseitigen Code-Teile vom Client, also von mir aus!) , an die der Forminhalt geht, darauf überhaupt angemessen reagiert, das Cookie-Setzen bei ungesetztem Häkchen also unterbliebe.
    Das gilt auch, wenn man im „theme“/template den ganzen Consent-/Cookie-Scheiß (id=“wp-comment-cookies-consent“) rausnimmt: wenn das php-script da etwas erwartet, das dann gar nicht (mehr) im post dabei ist …

    Eine kompliziertere Lösung kann auch die Sendungen vom Server rein CLIENTSEITIG natürlich übersteuern, z. B. den Cookie leeren, löschen, ganz woanders hin verschieben usw., kann also auch ohne die Kontrolle des Server-Codes auskommen, aber Kompliziertes ist dann oft nicht ganz so kompatibel mit nahezu allen Browsern bzw. erfordert das dann entspr. Prüfungen und Anpassungen je Browser-Typ (ca. 10 grobe Typen, deutlich über 2000 Versionen/Varianten), – der dann vlt. 10% Marktanteil hat …

    Da det Janze bisher so ausgelegt ist , daß comments-postings hier auch ohne javascript o. ä. aktiviert zu haben (zumindest in FF) funzen (sollten) (daher auch keine Eventfunktion), wäre die preemptive, serverseitige Lösung (Umgestaltung des Comment-Templates und/oder des PHP-Scriptes) wohl die beste Lösung, denn OHNE clientseitiges Scripting (-> Browsereinstellungen) ist man natürlich gegen das Einfallstor des (Mit-) Lesens (z. B. des Cookies) durch Dritte schon SEHR gut geschützt (wenn der Seitenbetreiber nicht anderen Murks einflicht), so daß man diese Option vlt. nicht killen sollte – aber die meisten Seiten performieren ohne scripting sowieso keinen smooth-run, so daß ohne seitenspezifische Scripting-An/Aus-Option im Browser die allermeisten ‚User‘ (Junkies!?) das Client-Scripting eher generell aktiviert haben.
    Hinweis: TECHNISCH muß die „https://www.theorieblog.de/wp-comments-post.php“ weder dem Pfad noch dem Dateinamen nach (auch für Admins!) nach NICHT vorliegen, – diese URL kann auch bloß ein Trigger (mit Daten-Space) sein, der die Kommentar-Daten zur weiteren Verabeitung (auf dem Server speichern, den Client veranlassen, einen Cookie entspr. Inhaltes zu setzen usw.) irgendwelchen schon geladenen Server-Prozessen übergibt, – die schlimmstenfalls nicht im Script-Modus bzw. Sourcecode auf dem Server liegen, sondern nur als vor- oder gar auskompilierter (als .dll z. B.) Run-Code, in den man nur SEHR SEHR SEHR aufwändig eingreifen (inject) oder ihn übersteuern kann (z. B. durch „wrappen“).

  5. Zu (1) … die Google-Fonts-Abfrage ersparen

    Was ist mit dem geposteten link? Das sieht doch gut aus, hier jetzt komplett:
    https://www.mittwald.de/blog/mittwald/howtos/dem-datenschutz-zuliebe-wie-ihr-google-fonts-lokal-in-eure-webseiten-einbindet
    Ca. 8-15 h Arbeit (NETTO!) für die ca. 10 Schritte.
    Angelt Euch doch mal 1-4 IT-Praktikanten aus Uni, FH, BFS, BS u. a., auch privaten, Instituten für sowas:
    Die DSGVO bzw. DSchutz und Third-Party-Unabhängigkeit bleiben auch auf längere Sicht beruflich HOCHAKTUELL/gefragt, und gute Praktika bzw. unvergütete (ggfls. aber „bezeugte“) Praxis-Projekte als (Teile von ) Abschnitts- oder Abschluss-Arbeiten werden dort immer wieder gesucht. Wenn’s dann doch mal ernster hapern sollte (nach entspr. Bemühungen/Recherchen), kann man/ich dem jungen Gemüse i. a. R. rasch weiterhelfen. Lern-/Übungsstoff gibt’s im DS-Bereich für einige 1000 Stunden … Vlt. tragt Ihr mal zusammen, was so ansteht und man kuckt, ob entspr. „Ausschreibungen“ und beherrschbare Strukturierungen dabei rauskommen können, ggfls. Chance zur Einarbeitung in ein IT-Project-Management-Tool usw. Eine TESTserver-mit-WP-Umgebung kann ja auch leicht (5-10 h netto) zuhause, in der Uni usw. installiert werden, und dort mal einige Wochen bis Monate laufen.
    WP ist eigentlich super (wörtl. „über“(-legen)) und extrem verbreitet, aber hinsichtlich Betreiber-Kontrolle und Clientschutz ein umfangreicher (schön, daß Ihr den gröbsten Mist schon rausgekick habt!) und auf den letzten Metern hartnäckig-aufwändiger Brocken, so daß entspr. Aktivitäten mit Sicherheit „Gemeinwohl“-Status beanspruchen dürfen.

    zu (2): das fehlende Häkchen wird DOCH reflektiert:
    ein ZUVOR gelöschter Cookie wird nicht wieder angelegt und es gibt auch keine Vorgabe von Name, email, Website mehr, checkbox wird OHNE Häckchen präsentiert, wenn das Häkchen beim Absenden entfernt ist.
    Vermutlich wertet einer der ca. 20-30 requests an theorieblog. de, die ein Seitenaufruf hier nach sich zieht, den automatisch mitversendeten (wenn vorhanden!) Cookie aus. Ist keiner vorhanden, weil eigens zuvor im Browser gelöscht UND fehlt der Haken, wird angenommen, daß die Setzung eines Cookies beim Kommentieren unerwünscht ist, – und entsprechend verfahren.
    Das ganze „Cooking“ (Senden,Empfangen, Setzen) ist eben AUCH http-basiert und beschränkt sich NICHT auf clientseitiges Scripting. Scriptloses Browsen ist dennoch ziemlich sicher, weil mit jedem http-request „nur“ der cookie des request-Zieles, einer hier eingebundenen Third-Party-Site z. B. , und NICHT der cookie von theorieblog.de übertragen wird (same-origin-policy, SOP), während eingebundene Scripte von Dritten diesen theorieblog-cookie auslesen und eigens versenden könnten (was bisher so nicht im Traffic aufgefallen ist).

    Allerdings ist davon auszugehen, daß Knoten wie s0.wp.com oder die google-fonts im grundlegenden Setup von WP (Geschäftsmodell) mit entsprechenden CORS-Einstellungen/headern (CORS= Cross-Origin-Resource-Sharing) ausgestatt sind, die diese Blockade (durch SOP) unterlaufen könnten (müsste ich in CORS-Doku nachchecken). Das sieht man an den http-headern, die ich noch nicht eingehend geprüft habe, bisher habe ich aber nur „sameorigin“ dort als policy gesehen …
    Die Reflektion der 2. Bedingung „Häckchen ist weg“ gibt mir noch Rätsel auf. Es gibt nur eine angezeigte Eventfunktion (die nur mit aktiviertem javascript wirksam wird) und zwar am html-tag angehängt. Von da aus kann auch ein element-event gehändelt werden … readyCallback() lese ich da u. a.
    Möglicherweise hängt es auch mit dem relativ neuen „for“-attribut beim Label(-Text) zusammen, daß direkt vor dem Absenden weder im HTML-QuellText, noch in den Script-Werten (des input-elements vom checkbox-Typ) die Änderung in der checkbox sich niederschlägt. … will see …

  6. Was in der mittwald-Anleitung zu den google-fonts NICHT (mehr) drin steht:
    Am Ende muß auf dem Server für das Verzeichnis der Schriften auch eine entsprechende MIME-Freigabe erteilt werden, also für .ttf-Files der „ttf“- bzw. „true-type-font“-MIME, für .woff-, .woff2-Files usw., halt für alle File-Endungen, die im Schriftenverzeichnis vorkommen. Das steht bei Mittwald nicht, weil es selbstverständlich ist, daß Dinge, die an Clients herausgegeben werden sollen, auch einer mime-Freigabe bedürfen, – es wird aber oft vergessen, weil .html-MIME- und andere grundlegende Mime-/File-Typen natürlich schon stets freigegeben sind.

  7. Ihr benutzt ja schon auf th…blog gespeicherte Fonts („… awesome …“ z. B., eine woff2-MIME).

    Der Request auf fonts.googleapis.com liefert das css („@font-face“ …) , worin konkrete Fontnamen mit einer google-URL (fonts.gstatic.com/…) verbunden werden. Deren Auflösung/Request/Anforderung kann ich (derzeit?) nicht sehen, womöglich weil schon geladen (nur page-reload durchgeführt), bzw. ‚im cache‘ (wobei ich auch schon cache-‚requests‘ gelogt habe, die im Moment aber wohl nicht angezeigt werden …)
    Aber neben dem css liefert fonts.googleapis.com auch einen LINK-header auf fonts.gstatic.com mit, dessen rel-‚Attribut u. a. auch einen „crossorigin“-Vermerk enthält. Sowas ist mit prefetching/preflights zum schnelleren Laden üblich. Verschiedene Doku-Stellen und Problemerörterungen (z. B. auf stackoverflow) legen nahe, das mit CORS bzw. Zulassung von cross-origin-content KEIN Zugriff auf die Cookies der Domain der gerade geladenen/angezeigten Seite (ohne iframes/frames mit anderem Domain-Ursprung darin) von solch dritter Seite erfolgen kann.

    Fonts-Ressourcen können aber auch aktive, ausführbare Codes enthalten, die ggfls. kompromittiert sind/sein können (inject) , nicht nur ‚passive‘ Daten. Das war vor 10-15 Jahren mal ein größeres Problem (-> on-the-fly-Infektion nur durch den Besuch einer Page, auch ohne jede Benutzerinteraktion wie auf einen Link klicken, Bestätigung einer download-/Installationsanfrage usw.) , so daß sich da ein restriktiveres Regime als für z. B. jpeg-Bilder u. a. passive MIMEs durchgesetzt hat.

  8. Lieber dos, aus privaten Gründen bin ich zuletzt an dieser Baustelle nicht weitergekommen, aber nochmals vielen, vielen Dank für deine vielen hilfreichen Tipps!! Sobald ich einen Moment Ruhe habe, setze ich mich daran. Denn ich fürchte, dass wir zumindest zeitnah keine Praktikanten kriegen…

  9. Ja, auch ich habe z. B. zwei für mich existenzielle Sozialklagen zu bewältigen, drück mir die Daumen.
    Anyway muß ich aber zur Entspannung eh‘ mal die eine oder andere Pirouette in Sachen IT drehen. Das sind dann aber nur Trippelschritte, nix zeitlich Stringentes.

    Der Cookie sollte verschwinden, wenn man das Erinnern-Kästchen abwählt. MIT js kein problem, aber ohne brauchte man eine http-codierte (header) Anweisung des Servers an den Browser. Ich wollte gerade da nachschlagen ob es analog zu set-cookie = „dies und das“ auch ein „delete/erase/cancel o. ä. auf http-Basis gibt, – da sehe ich Deine Replik.

    Wie ich inzw. lernen musste, gibt es in der DSGVO wohl auch ein eigenes Recht von Tieren spezifizierter Arten an ihren individ. Datenrecords, evtl. auch an ihren Bildern(?). Da ist die Frage, ob man den Bären im Icon nicht unrechtmäßig benutzt …, zumal schon die Box-Handschuhe eine Animation zur Tierquälerei darstellen könnten usw. Mit Sicherheit werden in/mit der DSGVO aber dem Publikum so manche andere Bären noch aufgebunden.
    ————————————————–
    Wäre nicht dem skandalträchtigen CEBIT-Auftakt (J. Lanier, Merkel) auch theoriemäßig hier zu begegnen ?
    Siehe meine Notizen hier dazu:
    https://www.freitag.de/autoren/dos/diary#1528765524738954
    ff.
    z. B.
    1. wert-theoretische Fundamentalien, grundlegende constraints „wissenschaftlicher“ Wertermittlung usw.
    2. Ausblicke & Strukturierungen des verbleibenden Restes wiss.-praktischer WE im Hinblick auf Daten, Merkelsche Verwendungen usw.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.