 Ja gut, wunderbar. Hallo zusammen. Raum 2, zweite Runde DSGVO, natürlich, wir haben kein anderes Thema, ist klar. Nachdem Udo und Ingo so ein bisschen eher theoretisch was erzählt haben, auch wenn es praktische Beispiele waren, geht es bei mir jetzt tatsächlich ausnahmsweise im WordPress. In Würzburg gab es einen Vortrag vom Torsten Landsiedel zu, was man so machen muss, wenn man in WordPress das alles anständig bauen will und auch welche Probleme man da so stößt. Und meiner ist ein bisschen ähnlich, ich habe mich auch mit dem Torsten abgesprochen. Es geht am Ende darum, was muss ich tun in meiner WordPress-Installation, um alles vollständig abzudecken. Disclaimer, das klappt nicht, das kriegen wir sowieso nicht hin, ich habe bestimmt auch irgendwas vergessen. Also insofern, es ist nicht vollständig, aber wir versuchen mal, was darüber zu sagen. Das bin ich, ja ein riesengroß, ich muss ein kleineres Bild wählen. Ich bin Diplom Informatik, ich mache Wartung, ich mache Sicherheit, laufe auch mit einem Shirt hier so rum und mache noch ein paar Meetups und paar Worldcamps. Sparen wir uns, weil wir brauchen Zeit für das hier. Die DSGVO Basics kennt ja auch schon alle, seit Ende Mai aktiv, es geht um personenbezogene Daten, speichern und verarbeiten generell nur mit Einwelligung oder mit ein paar anderen Beständen, Tatbeständen, die wir dann irgendwie noch gleich klären. Das schöne Übel bei einer Webseite, was uns regelmäßig Probleme macht, ist halt, dass die IP-Adresse des Besuchers auch unter die personenbezogene Daten fällt. Wenn das nicht wäre, wäre vieles sehr viel einfacher, ist aber so. Denn diese blöde IP-Adresse wird halt technisch notwendig andauernd übertragen, weil ohne die IP-Adresse geht es halt nicht, sonst geht kein Internet. Also müssen wir damit irgendwie klarkommen. Und das führt zu vielen Dingen, die auch gerne falsch gesehen werden und auch immer schön diskutiert werden. Und ein Thema ist Social Media Sharing und Embedding. Ist klar, was ich damit meine, also Social Media Sharing sind, also diese Buttons mit hier jetzt teilen, liken, irgendwas. Und Embedding ist, wenn ihr ein Social Media Inhalt, also ein Facebook Post, ein Tweet oder irgendwas in der Seite eingebunden habt, das ihr in der Seite lesen könnt. Also wohlgemerkt nicht als Zitat, sondern das Twitter-Facebook-Element selbst. Solang ihr einfache Links setzt, also mit HTML gesprochen, ein A-Tag ist alles egal. Dann müsst ihr nichts beachten, auch wenn das der ein oder andere schon mal anders sieht oder fragt. Also normale Links sind niemals ein Problem, auch wenn der Link schön bunt gestaltet ist. Also auch wenn der Link in Form eines bunten blauen Facebook Buttons daherkommt, ist es immer noch nur ein Link. Das Einzige, wo es Probleme gibt, sind die Share Buttons, die von den Netzwerken selber kommen, die ja dann mit irgendwelchen Daten von diesem Netzwerk geladen werden, wo dann auch hintersteht. So und so viele Leute haben schon geliked oder geschert. Da übertragt der Daten an zum Beispiel Facebook und diese Datenübertragung ist ein Problem. Einfache Lösung, weglassen. Diese Buttons einfach nicht einsetzen. Share Riff Rapper, zum Beispiel, werde ich regelmäßig gefragt. Also wirklich regelmäßig, ist der ein Problem? Nein, ist er nicht, weil das sind nur Links. Und das Einzige, was der Share Riff Rapper tut, ist unter Umständen so Share Counts zu zählen. Also die, wie wie ich wurde dieser Beitrag schon geteilt, das macht er aber serverseitig. Also da wird die IP-Adresse vom Server übertragen an Facebook. Aber das ist nicht euer Problem. Also das ist immer nur die Besucher IP Adresse, die das Problem ist. Also Share Riff ist nie ein Problem. Meiner Meinung nach muss Share Riff auch nicht in der Datenschutzerklärung stehen. Weil es Humbug, warum sollte ich da was reinschreiben, was unproblematisch ist. Es gibt aber Datenschutzgeneratoren, die das tun, die tatsächlich einen Abschnitt haben zu diese Seite nutzt Share Riff Rapper. Und Achtung, genau, der Anbieter ist GitHub steht da, weil man den Share Riff Rapper ja auf GitHub runter laden kann. Nein, GitHub ist nicht der Anbieter von Share Riff Rapper. Der Anbieter von Share Riff Rapper ist heute hier. Nicht in diesem Raum, aber in irgendeinem anderen Raum ist er. Nein, und er ist nicht der Herr GitHub. Also das ist Humbug. Wenn ihr das seht, ist vollkommen der Quatsch. Am besten streicht ihr die Absätze komplett raus zum Share Riff Rapper. Ja, die sind unnötig. Weil ist halt nun Link. Problematischer ist aber das M-Bett, also das Einbetten eines Inhalts. Also sowas hier. Also so dieser, so ein Tweet, der irgendwie im Fließtext eures Blog beitragst. Wenn ist das, dürft ihr nicht einfach so machen. Ich weiß, es ist schade, aber dürft ihr nicht. Hintergrund, ihr übertragt natürlich IP-Adresse an Twitter, einerseits, aber wenn ihr bei Twitter eingelockt seid, als Besucher, werden natürlich, weiß Twitter auch viel mehr von euch, weil der Twitter Cookie ist noch da, ihr seid eingelockt, Session und so weiter, dann kann Twitter da sehr viel mehr von ablesen, Facebook natürlich genauso. Deswegen, Einbindung von sowas, nur noch Einwilligung. Und wie bekommt ihr diese Einwilligung? Im einfachsten Fall mit einer 2-Click-Lösung. Das Wort werde ich heute noch fünfmal sagen, 2-Click-Lösung. 2-Click-Lösung bedeutet im Prinzip, dieser Tweet wird nicht sofort geladen, sondern da steht einfach irgendwas anderes, Button oder irgendwie ein Link. Und erst wenn ihr da draufklickt, wird das ganze geladen. Damit eine Einwilligung, weil natürlich dieser Link, den ihr klickt, da steht drauf hier, passt auf, wenn du das jetzt tust, dann lädst du was von Twitter. So wie hier, klickiert du DisplayContent vom Twitter und wenn du da dann draufklickst, weißt du, was du tust. Das da kommt aus einem Plug-in. Das Plug-in heißt Ambit Privacy von EP-Füte. Der Simon hat mir auch erklärt, was es bedeutet. Ich habe es schon wieder vergessen. Das Licht aus, keine Ahnung, wie es geht. Ja Treffer, sehr gut. EP-Füte, also der Simon Kraft macht das, das ist ein schönes Plug-in. Das sieht in seiner Standardform nicht so nice aus, also so mit schwarzem Hintergrund und weißer Schrift und dies auch noch in Englisch. Aber das kann man mit CSS und ein bisschen Übersetzung, so was kann man das in seine Richtung biegen. Damit könnt ihr solche Ambits einbauen und wenn derjenige den sehen will, klickt da einmal drauf und dann wird der geladen und dann habt ihr eine Einwilligung geben. Prinzipiell kann man solche Einwilligungen ja dann im Cookie speichern und dann ist die einmal gegeben und dann funktioniert das für alle anderen Ambits natürlich automatisch. Da kann man jetzt noch ein bisschen darüber streiten, ob da jetzt noch ein Hinweis auf die Datenschutzerklärung drinstehen muss und ob die verlinkt sein muss. Da könnte man jetzt den Udo sofort fragen. Ich persönlich würde sagen, das reicht, weil das dann Datenschutzerklärung in der Ecke irgendwo links unten irgendwo rumsteht weiß ja jeder. Das darf der Udo aber gerne was zu kommentieren. In der Datenschutzerklärung muss natürlich was von Twitter drinstehen. Klar, also wenn du ein Twitter-Ambit einbaust, muss dann Abschnitt zu, was passiert, wenn du da draufklickst, dann lädt was von Twitter, das muss da drinstehen. Aber das müsste sowieso. Das ist mir egal, Bernhard. Hast zwei Varianten, also die Variante ist ja, du sagst, ich habe da berechtigtes Interesse daran, dass ich das tue, weil es irgendwie wichtig für mein Blogbeitrag, dass es irgendwie schön aussieht. Berechtigtes Interesse impliziert aber, dass es einen opt out gibt. Dann müsstest du einen opt out anbieten auf deiner Seite für jemanden, der eben nicht Twitter im Bett sehen möchte. Ich weiß nicht, ob du da für eine technische Lösung hast. Ich so spontan habe ich keine. Und die zweite Variante ist natürlich, der ist mit der Einwilligung ist ja immer so eine Sache. Also manche Sachen könntest du wegargumentieren, wenn du mit dem Dienstleister, mit dem Anbieter, dem du irgendwelche Daten überträgst, ein Vertrag zur Auftragsverarbeitung hast. Hast du den mit Twitter? Twitter wird dir niemals einen solchen Vertrag vorlegen. Insofern ist das schon eine eher problematischere Übertragung und damit Einwilligung. Auch wenn es blöd ist. Ich sehe es ein. Es ist so nicht schön, aber es ist, ob jemand dich deswegen abmahnt, das ist eine ganz andere Frage. Aber es geht ja um die Theorie. Also um eigentlich musst du das so tun. David. Im Fall von so einem Twitter im Bett, wer da technisch die schlaure Lösung nicht, das eben auch serverseitig zu machen und dann gegebenenfalls zu cashen, weil dann entfällt für den User der lastige Klick und wird auch nichts übertragen. Na ja, also geht es ja bei dem Embed meistens nicht um das Design von Twitter, sondern um den Tweet. Und es gibt natürlich Methoden, den Tweet zu ziehen über die API und in eigenem HTML darzustellen und quasi aktualisiert, aber immer wieder einzubinden. Also welche Antworten und wie viele Likes und sonst irgendwas. Klar ist immer eine Variante, wenn das das darfst du natürlich, weil warum solltest du serverseitig nicht irgendwas über eine API abziehen dürfen. Ja, ja, Urheberrecht Bilder ist immer so ein Thema. Wenn du aber eine Quellenangabe hast und etwas zitierst, ist das ja, ja, wie immer ist es schwierig. Also meine preferierte Variante wäre das Prinzipiell. Da kommt es halt einmal darauf an. Das ist gleich bei den Videos, kommen wir zu dem Thema ja auch. Das ist so bei Videos gibt es auch mehrere Varianten, wann es schlau ist und wann nicht. Also David sagt, dass es ein Problem mit Caching Pluckins gibt. Sehe ich jetzt noch nicht. Erhelle mich. Also das wird ja dynamisch eingesetzt und bleibt natürlich dann auch dynamisch. Also quasi gekächt ist ja das hier und der Rest passiert ja dann dynamisch. Und das gekächt ist ja nicht schlimm. Jetzt mal abgesehen von Zitatproblemen und sonst irgendwas. Finde ich das mit dem Einwilligung am schönsten. Wie gesagt, wenn man die Einwilligung ja einmal gibt, also bei einem Tweet bleibt das Ding ja dann potenziell erhalten. Wobei ich nicht weiß, ob das bei Embed Privacy so ist oder ob das in der nächsten Version kommt. Also ob man jeden einzeln immer bestätigen muss oder ob das einmalig dann auch ein Cookie hinterlegt wird. Das wäre dann unter Umständen Option. Ja, pro Dienst natürlich, immer sowieso. Das ist das zweite Thema hatten wir eben im vorherigen Vortrag schon so ein bisschen was zu. Google Analytics, Matomo und hast nicht gesehen. Ich renne immer noch auf vielen Seiten rum, die keine IP Anonymisierung haben. Ich habe dazu heute morgen noch eine E-Mail gelesen. Das machen wir aber nur, wenn wir dadurch keine Nutzerdaten verloren gehen. Ja, nee, weil IP Anonymisierung ist also auch vor DSG4O schon Standard. Das ist nichts Neues, das Map, der schon die ganze Zeit haben müssen und nein, es gehen keine großartigen Nutzerdaten verloren. Also die einzige Frage, die ja verloren geht, ist eine sehr viel genauere Geolokation, die man im Regelfall an der Stelle auch boppen kann. Anonymisierung bedeutet ja nicht, dass die komplette IP Adresse wegfällt, sondern nur der hintere Teil, sodass man eine grobzuordnung zur Region immer noch machen kann. Und natürlich braucht ja immer einen Vertrag mit Google, also den Vertrag zur Auftragsverarbeitung. Den hätte die aber auch, glaube ich, vorher auch schon gebraucht. Also insofern ändert sich auch da nichts, aber haben die meisten nicht. Also darf man immer wieder noch erwähnen, ist aber kein DSG4O Thema. Und das einbinden ist dieses Google Analytics Codes. Das geht ja auf unglaublich vielen verschiedenen Varianten. Das gibt es bei manchen Teams, gibt es Team-Optionen dafür, wo man das einfach nur die Analytics ID dann eingibt und der Rest macht das Team. Manche Leute haben Childs Team und haben die Head-Up-PAP bearbeitet und haben das selbst reingebaut. Es gibt diverse Plugins mit dem, dass man machen kann. Und man sollte sich sehr genau überlegen, was man da tut und das mal überprüfen, weil von mir auch sehr regelmäßig gesehen, wenn man also ein Team hat, wo man in den Team-Optionen einfach nur die Analytics ID angeben muss und das Rest macht das Team, dann sollte man mal gucken, ob da sowas wie eine IP-Anonymisierung auch wirklich aktiv ist. Das ist nämlich meistens nicht. Und dann sollte man diese Team-Variante weglassen und das dann vielleicht doch mit einem Plug-in machen, wo man halt sehr genau kontrollieren kann, dass die IP-Anonymisierung dabei ist. Also da lohnt es sich, bei zu gucken. Und dann, ich überspringe mal den Punkt und komme zum letzten, Cookie-Bunner, den hatten wir eben schon mal, das Thema Cookie-Bunner, das kommt auch gleich nochmal ausführlichst. Ihr braucht für Google Analytics ein Opt-Out. Die Menschen müssen sagen dürfen, ne, ich will nicht. Ihr braucht aber ein Opt-Out, das heißt, die Menschen müssen nachträglich sagen können, ne, ich will nicht mehr. Ihr braucht aber kein Opt-In. Also nicht beim Besuch der Seite, ja, ich will, ja, braucht ihr nicht. Kein Cookie-Bunner dafür. Das Opt-Out braucht ihr aber definitiv und ihr braucht dieses Opt-Out ausreichenderweise in der Datenschutzerklärung. Da muss ein Opt-Out drin sein. Das geht auf verschiedenen Varianten. Es gibt so Rauserplakken dafür und so, kann man alles Mögliche machen. Idealerweise gibt es aber auch so ein Opt-Out-Link, den ihr da einfach einbaut. Und dafür gibt es eine Methodik von Google, das gibt es so einen kleinen JavaScript-Funktionen, ist kein Problem, wenn da nicht der WordPress-Editor wäre. Ein WordPress-Editor, der, wenn man da jetzt so eine Datenschutzerklärung, die man irgendwie dem Generator erzeugt hat, da rein pastet. Alles ist gut, aber der Link ist ein Link mit einem JavaScript-Aufruf drin und der WordPress-Editor löscht diesen JavaScript-Aufruf raus, weil der WordPress-Editor säubert das HTML. Dann habt ihr da zwar einen Link drin stehen, der macht aber nichts. Das doof, weil dann habt ihr kein Opt-Out. Deswegen solltet ihr euren Opt-Out-Link, wenn ihr den drin habt, einfach mal überprüfen, ob er auch wirklich funktioniert. Übrigens, der setzt ein Cookie, und zwar ein Opt-Out-Cookie. Dieses Cookie ist vollkommen okay, weil es ist technisch notwendig, weil ohne das Cookie weiß er nicht, dass ihr kein Tracking wollt. Also kann man das so machen. Idealerweise macht er es also nicht so, sondern mit einem Shortcode, den ihr in diese Datenschutzerklärung einsetzt, den es von diversen Plugins gibt, heißt zum Beispiel ein Google Analytics Opt-Out. Gibt es einen Shortcode, den baut ihr ein, dann kommt der Link, der funktionierende Link sauber rein. Für Matomo Pivic gibt es einen Opt-Out-Frame, was ihr einfach einsetzen müsst. Also meine Anmerkung war, was ich bei meinen eigenen Seiten und bei anderen kleineren Seiten gemacht habe, ist brauche ich Analytics überhaupt. Wenn ich da einmal im Monat reingucke und mich freue, dass ich 300 Besucher auf der Webseite habe und keinen Geld für Werbunginstrumente ausnehme, das heißt keine tiefen Analyse meines Traffics brauche. Statify oder komplett drauf verzichten, speich mir den ganzen Stress an der Stelle. Ja, das ist definitiv der Fall. Ich glaube, Bernhard wollte noch was sagen. Ja, so noch ein Hinweis zu dem JavaScript-Code, der zerstört wird. Wenn man administrativer Seite ist, bleibt da drin. Und das auch so ist, dass die Datenschutzseite, die eingestellt ist als Datenschutzseite, nur von Administraturen bearbeitet werden kann, kann das trotzdem funktionieren. Man muss halt natürlich sicherstellen, dass der Code nach dem Speichern noch da ist. Aber als Administrativer bleibt JavaScript-Code im Elientor erhalten. Ja, also es kann funktionieren. Ja, auch On-Click-Code? Ja. Sicher? Ja. Okay. Also okay, da bin ich mir nämlich tatsächlich an der Stelle nicht so sicher. Spätestens hast du aber ein Problem damit, dass dieses On-Click eine JavaScript-Funktion aufrufen möchte, die du auch irgendwo haben musst. Also die zusätzlich irgendwo liegen muss. Also der On-Click ruft eine JavaScript-Funktion, auf die natürlich irgendwo definiert sein muss. Und spätestens den Code musst du noch irgendwo hinbauen. Und spätestens dann möchtest du so einen Plug-in haben und das vielleicht so machen. Aber müssen wir noch mal gucken. Also ich bin mir da nicht so sicher. Ich will das jetzt nicht verneinen, aber ich bin mir zumindest nicht sicher. Bei Matomo gibt es ja die Möglichkeit, das auch ohne Cookie zu betreiben. Und wenn man dann noch die IPs anonymisiert, ist dann überhaupt ein Hinweis in der Datenschutzerklärung notwendig? Ja. Sind es wirklich dann noch personenbezogene Daten, die übrig bleiben? Also verstehe, danke. Deswegen lasse ich dann solche Sachen immer euch beantworten. Und kommen wir zu meinem allerliebsten Lieblingsthema Cookie-Banner, was ja quasi mit dem Matomo-Pivic Google Analytics so ein bisschen was zu tun hat, weil alle Leute ja natürlich deswegen irgendwie mit einem Cookie-Banner unterwegs sind. Und wie Udo und Ingo eben schon sehr richtig in der vorherigen Session gesagt haben, sind Cookie-Banners in den allermeisten Fällen vollkommen nach Humbug. Insbesondere Cookie-Banner, die genau so aussehen, das ist ein Screenshot von vorgestern aus einem Kundenprojekt, also dem ich nicht diesen Cookie-Banner gemacht habe, logischerweise. Unsere Website nutzt Cookies, um eine bestmögliche Funktionalität bieten zu können, okay. Also wenn man schon ein Cookie-Banner einbaut, dann lässt dieser Cookie-Banner alles vermissen, was auch nur ansatzweise relevant für so ein Cookie-Banner hätte sein können. Nämlich die Möglichkeit ja und nein zu sagen, das ist ja schon mal so eine Basis. Wenn man ein Opt-In machen möchte, Opt-In bedeutet ja Zustimmung, aber dann muss man auch eine Auswahl haben. Und also wenn ich schon Cookie-Banner baut, dann hätte ich da auch ein Link zur Datenschutzerklärung haben können. Klar, dann habe ich auch irgendwo anders, aber wenn ich schon so ein Banner mache, um meine Besucher explizit darauf hinzuweisen, dann fände ich so ein Link zur Datenschutzerklärung da drin auch irgendwie hilfreich. Aber mit nur okay ist er sowieso sinnlos. Wenn dann würde ich, also wenn ich unbedingt ein Banner haben will und unbedingt meine Besucher damit plagen möchte, dann sollte es ein Banner sein mit ja und nein. Der dann aber auch genau darauf reagiert, das heißt der Google Analytics Code wird auch erst geladen, wenn jemand auf ja geklickt hat und er wird nicht geladen, wenn jemand auf nein geklickt hat. Dann also auch bitte mit genau der Funktion. Die allerwenigsten haben genau so ein Cookie-Banner drin. Das wäre noch so ein, den ich akzeptiere übrigens, sollte es idealerweise ja die Möglichkeit geben, diese Einwilligung auch wieder zurückzunehmen. Also vielleicht sollte man dann auch irgendwo noch den Link haben, quasi seine Entscheidung noch mal zu revidieren. Also da sind Fragen, wo ich mir denke, ich mache keinen Cookie-Banner. Vielleicht brauchen wir den irgendwann nächstes Jahr mit der ePrivacy-Richtlinie. Vielleicht aber auch nicht. Und da wir das nicht wissen, müssen wir uns jetzt nicht darum kümmern und deswegen ignorieren wir dieses Thema. Und wenn der Cookie-Banner das Impressum und die Datenschutzerklärung überdeckt, dann sind wir sowieso noch abmanfälliger, als wir jemals vorher waren. Also lassen wir das Ding einfach sein. Denn, haben wir jetzt schon ein paar mal gesagt, für Analytics Matom und so reicht ein Opt-Out in der Datenschutzerklärung kein Cookie-Banner. Der Cookie-Banner wäre unter Umständen notwendig für so was wie Facebook Pixel oder was hast du noch eben gesagt, bestimmte Werbennetzwerke unter Umständen, für die man tatsächlich ein Opt-In benötigt, weil sie über die Websitegrenzen hinweg personen tracken. Und das ist etwas, wo man dann tatsächlich über ein Opt-In redet. Und das ist aber auch der einzige Fall. Oder man macht es so, wie Udo das manchmal tut, weil er keine neffigen Nachfragen haben möchte und deswegen trotzdem einen anbietet, ohne ihn zu brauchen. Aber sowas mehr nicht. Keine Cookie-Banner. Danke. Ich hätte die Frage vielleicht vorhin stellen sollen. Aber ich bin technisch jetzt nicht so bewandert. Fingerprinting oder wie wird das genannt? Also diese anderen Tracking-Methoden, die jetzt keine Cookies mehr benutzen, da geht aus meiner Sicht so ein bisschen auch der Trend hin. Was ist damit eigentlich? Es gelten genau die gleichen Regeln. Also ob du jetzt einen Cookie nimmst oder eine andere Art des Tracking, Fingerprint Tracking ist vollkommen egal. Wenn es ein Tracking ist, brauchst du entsprechend unter Umstände die Einwilligung. Wenn es nur über die Web-Analyse geht, brauchst du es dann nicht. Das Ding dabei ist ja nicht, dass es das Cookie ist, was das Problem ist, sondern das Tracking. Also dass es über ein Cookie fassiert, ist ja jetzt quasi nur technischer Zufall. Deswegen über ein Cookie-Banner, nicht über ein Tracking-Banner reden. Du kannst auch einfach über ein Tracking-Banner reden oder eine Tracking-Einwilligung und dann weißt du es. Also das Cookie an sich ist ja quasi nur das technische Hilfsmittel. Videos ist im Prinzip genauso wie eben diese Social Embeds, dasselbe Thema. Nö. Das Problem ist, gerade bei einem Video ist es ja noch relevanter, dass man irgendwas sehen möchte. Also so irgendeine Vorschau oder so. Deswegen gibt es da tatsächlich diverse Plugins für, also dieses Embed Privacy Plugin, was ich eben bei den Social Embeds genannt habe, kann das auch. Alle Embeds in WordPress, dazu zählt auch YouTube und Vimeo. Aber es gibt so ein paar spezielle WP YouTube Live und Embed Videos and Respect Privacy, die tatsächlich so ein Vorschaubild zeigen oder auf jeden Fall ein irgendwas geartetes zeigen. Zwei Klicklösungen wieder. Es gibt das Awarda-Theme, was ja auf so einem Wordcamp umfällt, immer als böse, böse, böse, multipurpose-Theme bezeichnet wird. Ich erwähne es trotzdem. Das hat eingebaute Consent Settings, so mit Zustimmung und zwei Klicklösungen und so. Und die Vorschaubilder von diesen YouTube-Videos, also bevor man das abspielt, die darf man aber auch nicht laden von da, weil auch das Vorschaubild ist ja schon ein Zugriff auf YouTube. Und deswegen gibt es tolle Lösungen wie zum Beispiel bei WP YouTube Live, die auch das Vorschaubild von YouTube laden auf dem eigenen Server abspeichern und dann nur vom eigenen Server aus auf der Webseite anzeigen, weswegen die Besucher-IP nicht an YouTube übertragen wird. Alles sind glücklich, alles sind froh und dann kommt der Ude und sagt mir, ne du, pass mal lieber auf, weil wenn du diese Vorschaubilder lokal speicherst und es ist nicht dein Video, also dein eigener Kanal, dein eigenes Video hast kein Recht dran, dann ist vielleicht das Speichern des Vorschaubilds auf deinem Server eine Urheberrechtsverletzung. Und dann denkst dir auch, schade. Also wer solche Lösungen einsetzt, kann das gerne tun, auch mit einem Vorschaubild. WP YouTube Live funktioniert wunderbar, aber bitte nur bei eigenen Videos. So bald ihr Videos von anderen Leuten einfügt, nehmt hier eine Lösung, die kein Vorschaubild zeigt, so wie in Bad Privacy oder so, wo ihr einfach nur ein buntes Bildchen habt, wo jemand okay klickt. Auch das ist schade und unschön, seh ich ein, ist aber nicht zu verhindern. Bei WP YouTube Live habt ihr da so hier Cash Thumbnails Locally und No ist übrigens default. Das bedeutet, WP YouTube Live lädt das Vorschaubild trotzdem von YouTube, nicht das ganze Video, aber das Vorschaubild wird trotzdem davon dargezogen, ist also aus DSGVO Sicht genauso quatsch. Man muss zur Verteidigung dieses Pluckins aber sagen, es ist aus Performance Gründe gebaut worden. Es ist kein DSGVO Pluckin, sondern es ist ursprünglich entwickelt worden aus Performance Gründen und dann hat der Entwickler festgestellt, auch ja, geht ja auch für die DSGVO. Also man muss da, wenn man das will, dann von No of Yes stellen, dann werden die Thumbnails lokal abgespeichert und man kann mittlerweile unter diesem Vorschaubild ein HTML Code anzeigen, der dann sowas heißt wie, ne, mit Abspiel des Videos stimmen sie an der Übertragung der Daten an YouTube zu, hier ist unsere Datenschutzerklärung, da muss natürlich auch was zu YouTube drinstehen. Kann man machen bei eigenen Videos. Der Gert fragt nach den No Cookie YouTube Embeds, die gibt es, das reicht aber nicht, weil dann werden immer noch Daten an YouTube übertragen, auch wenn YouTube nicht die Cookies auswertet oder keine Cookies speichert, aber Daten an YouTube, IP Adresse wird immer noch übertragen. Hilft ihr also nicht, hilft ihr ein bisschen, aber nicht ausreichend viel. Genau, es ist nicht ganz gut, aber ein bisschen gut, aber wir wollen ja ganz gut sein. Das ist ein Screen aus Avada. Zu dem oberen Teil davon komme ich gleich noch, der rote Teil ist das Interessante, da kann man auch Privacy Content, Konzent anschalten und dann gibt das das für YouTube, für Vimeo, für Soundcloud, für Facebook, für Flickr und haste nicht gesehen, auch für Google Maps, sodass da auch überall ne zwei Klicklösung kommt, macht Avada an der Stelle tatsächlich relativ nett, weist oben darauf hin, dass dafür ein Cookie gesetzt wird, um zu wissen, wer wann, welche Konzents gegeben hat, und dass mir den Cookie doch bitte dann aber in der Datenschutzerklärung erwähnt. Na ja, Google Maps ist auch ein Embed, ne? Es sind alles Embeds, ich teile sie nur noch mal einzeln auf, man fügt irgendwas von irgendwem anders ein auf der Webseite und das darf man auch nur noch ein wenig, weil es ist ja was, was von Google geladen wird, ob das jetzt ein YouTube Video ist oder ein Google Map ist vollkommen wurscht. Es gibt Gott sei Dank ein paar Map Plugins, die so GDPR Funktionen drin haben, da oben stehen so ein paar, also WallApps Cookies ist immer so ein Standard Plugin, was so ein Cookie Banner eigentlich macht, kann aber diese ganzen Third Party Dinger auch mit Einwilligung umbauen, die oben beiden, oben die WP Google Maps und Map Press in zwei spezielle Google Maps Plugins, die so eine GDPR Freigabe Funktionalität haben. Avada hat das auch, haben wir mal auf der vorherigen Folie gesehen. Und das ist so der Running Gag, ne? Google Maps, wenn also die Zustimmung zu Google Maps gegeben wird, ist alles in Ordnung, kann geladen werden, dann darf auch der Google Font geladen werden, den die Google Map LED, Roboto, aber in eurer Datenschutzerklärung sollte nicht nur ein Eintrag zu Google Maps stehen, sondern auch zu Google Fonts, weil ja, Google Map ein Google Font LED, ihr habt zwar, der Besucher zwar die Einwilligung dazu gegeben, ist okay, man muss trotzdem in der Datenschutzerklärung stehen, wenn ihr sonst keine Google Fonts habt. Es gibt allerdings auch Möglichkeiten, mit denen man den Google Font aus der Google Map rausbauen kann. Also, dass der nicht mitgeladen wird, das möchte der Marvin bestimmt an dieser Stelle sagen. Das ist nicht, dass keine Google Font Schrift gezeigt wird über die Google Maps, im Endeffekt anders angezeigt wird, die ja nicht. Dadurch, also die Roboto Schrift, die wird ja dann nicht mehr geladen, ich mach das über Functions PAP und Shavascript, aber warum ist ja überhaupt da drin? Oder warum wird die mitgeladen? Also anders angezeigt wird sie bestimmt. An der ein oder anderen Stelle wird Google diesen Font nutzen, vielleicht aber nicht für eine einfache Karte, sondern vielleicht für die Pins, wenn da irgendwie so ein Feld aufgehen soll, da wird dann schon eine andere Schrift kommen. Also, man braucht ihn nicht zwingend, aber standardmäßig kommt der einfach mit. Man muss es also entweder irgendwie verhindern oder, weil du für die Maps sowieso eine Einwilligung brauchst, mit der Einwilligung gibst du die Einwilligung für die Google Map, dann darf da auch ein Google Font mit drin senden, dann musst du halt nur den Font halt auch in der Datenschutz Erklärung erwähnen, also der Absatz mehr und dann ist halt an der Stelle auch gut. Vergiss man nur gerne, das ist so das entscheidende Element an der Stelle. Hallo, wenn man jetzt diese Font vergisst, ist man ja schon wieder abmannfähig, oder? Theoretisch. Gibt es denn schon Abmann wählen wegen so einem Kleinkram? Nein. Und gibt es? Ja, aber wo könnte man? Weißt du, das Ding ist, das Ding ist es wird für alles immer irgendwo eine Abmanung geben und es wird auch sicher alles abgemannt werden. Nur das Ding ist ja. Ja, wo kann man sich dagegen ein bisschen verbünden? Gibt es da was zentrales? Du musst dich nicht verbünden, weil es gibt keine Abmannwelle. Ja, also diese berühmte Abmannwelle passiert nicht. Also der Datenschutz beauftragte, mahnt dich ja nicht ab, der Datenschutz beauftragte prüft unter Umständen. Der wird dich spontan wegen so etwas definitiv nicht prüfen. Aber und, und, wenn eine Abmahn, wenn jemand dich abmahnen möchte, dann muss das ein Mitbewerber sein oder sowas wie die Verbraucherzentrale. Die Verbraucherzentrale wird jetzt ohne, dass du den jetzt ganz große Dinge getan hast, auch nicht spontan auf die Idee kommt, dich deswegen abzumahnen. Okay. Und der Mitbewerber, das ist auch so ein Punkt, den Udo eben im vorherigen, in der vorherigen Session gesagt hat, der Mitbewerber, der dich wegen einem Googlefront in einer Google Map, die du eingebunden hast, abmahnt und zu der Google Map hast du eine Einwilligung gegeben, dir fehlt nur der Text in der Datenschutzerklärung zum Google Front aus der Google Map. Wenn er dich deswegen jemand abmahnt. Also ich garantiere dir, auf der Webseite des Mitbewerbers findest du mindestens 10 andere Punkte wegen den Dingen kannst du den abmahnen. Also das ist etwas, also es gibt keine Kanzlei, die das Web-Screen nach irgendwas, um irgendwas zu finden. Und selbst wenn die Kanzlei es tun würde, die Kanzlei braucht einen Mitbewerber von dir, um dich abzumahnen. Die Kanzlei darf das nicht. Danke. Willst du nicht wissen, wie viele Folien ich noch habe? Das selbe gilt übrigens auch für Open Street Map, das gerne als die Alternative zu Google Maps ausgedacht und vorgeschlagen wird. Ja, Open Street Map ist natürlich genauso externe Daten, müssen genauso eingewilligt werden. Das ist vielleicht nicht ganz so problematisch wie mit Google, aber Einwilligung braucht mal trotzdem. Und auch hier an der Stelle darf man daran denken, dass die Open Street Map Server sehr, sehr häufig in England stehen und die Open Street Map Foundation, die das ganze so über Dachdeckelt auch in England sitzt und jetzt denken wir an dem Brexit und wissen, dass es keine EU mehr ist und wenn das keine EU mehr ist, dann gilt das die DSGVO nicht mehr und dann Vorsicht. Deswegen dann deutsche OSM Server nehmen und da kommen wir natürlich dann an Punkte, wo man eine Konfiguration kommt, wo man das vielleicht nicht immer einfach so deswegen ist, das vielleicht ein bisschen schwieriger für den ein oder anderen. Ja, genau, man kann natürlich viel tun. Es gibt ja auch OSM Pluckins fertige. Ich weiß gar nicht, wie gut man da drin die einzelnen Server dann auswählen kann, die man nutzen wollen möchte. Man hat auf jeden Fall technische Probleme an der Stelle. Ja, das ist die beste Lösung. Tochter, Karte malen lassen ist immer in Ordnung. Ich habe im Vorfeld von im Mai mal mit dem Entwickler von einem, dieser OSM Pluckins, korrespondiert, um die Idee aus zu prüfen, inwieweit man tatsächlich dann vorlädt, auf den Server ein Vorschaubild generiert und dann mit Einwilligung die Karte anzeigt. Der war dann nicht abgeneigt hat, aber auch jede Menge zu tun, wie wir alle. Der Vorteil da wäre allerdings, dass es natürlich lizenstechnisch mit OSM wesentlich einfacher ist, diese Kacheln anzuzeigen, weil das halt ja erlaubt ist, es ist eine freie Inhalte. Man muss nur richtig lizenzieren, während man eine Google Map natürlich nicht die Kacheln einfach mal vorladen und anzeigen kann. Es gibt ja bei der Google Map gerne die Idee, ein Screenshot von Google Maps zu machen und den dann stattdessen anzuzeigen. Das ist aus DSGV Osicht kein Problem, aber das ist Urheberrechtsverletzung. Bei OSM ist das tatsächlich nicht so das Problem, wenn man die entsprechenden Lizenz hinweise dann zu OSM an der Stelle gibt. Ich hatte in einem OSM Forum allerdings gelesen, dass man nicht sicher sein kann, selbst wenn man die deutsche API von OSM benutzt, dass dann wirklich nur von deutschen Servern geladen wird. Das ist leider das Problem. Also ich konnt's nicht nachprüfen, aber das wurde da auch diskutiert. In diesem kompletten OSM Thema ist die Nachprüfbarkeit sowieso am allerschwierigsten, weil es ein relativ offenes Open Source Projekt ist. Insofern ist Nachprüfbarkeit schwierig. Alle Fragen werden wir niemals fertig. Die Fragen verschieben wir aufs Ende und nach dieser Session für Individual, weil ich bin bei, weiß ich nicht, Folie von, da kommen noch ein paar. Deswegen huschen wir jetzt ein wenig durch, es wird auch nicht mehr langweiliger. Google Fonts hat mal eigentlich schon gesagt, Google Fonts sind auch so ein Problem und eigentlich auch nur nach Einwilligung. Einwilligung Google Fonts macht keiner, ist blöd. Dann gibt's gerne berechtigtes Interesse als Argument. So berechtigtes Interesse an schönem Design und so. Berechtigtes Interesse beinhaltet aber immer einen Opt Out. Ich weiß nicht, wie ihr das Technik umsetzen wollt. Ich kenne keine Lösung, wie man in der Datenschutzerklärung einen Opt Out Link für Google Fonts klickt und danach werden alle Google Fonts tatsächlich nicht mehr geladen. Kann man natürlich theoretisch bauen, technisch ist das eher Humbug. Abgesehen davon, dass das Argument mit berechtigten Interesse im Regelfall abgewiegelt wird und sehr schwach ist, weil es die Dinger zum runterladen gibt. Also es gibt keinen Grund, warum man die Zwingen vom Google Server laden muss. Es ist ein Open Source Font mit einer Lizenz, die erlaubt, sie lokal zu speichern und dann darf man diese natürlich auch lokal speichern und da wird jeder Datenschutzbeauftragte sagen, dann mach's doch. Also es gibt keinen Grund, die vom Google Server zu laden. Technisch vielleicht schon, weil es einfacher ist, aber jetzt nicht aus Datenschutzsicht. Es ist nicht zwingend schneller manchmal schon ein bisschen. Naja, häufig wird so diese Anpassung über das Shield Team empfohlen, so da irgendwas ausbauen und Google Fonts lokal einbauen. Das geht gut, wenn das Team gut programmiert ist und wenn die Plugins gut programmiert sind, dann kann man das solide umsetzen. Man rennt relativ schnell gegen Wände, wenn man das wirklich vollständig versucht und wenn der Kunde lustige Dinge einsetzt. Ich nenne noch keine Namen, aber vielleicht auf der nächsten Folie. Dann wird man mit dieser Lösung scheitern, weil die den nicht WP-konformen Weg machen und dann hat man keine Chance, dann klappt's nicht. Ich nutze deswegen sehr häufig das Plugins Self Hosted Google Fonts, was nichts anderes macht als serverseitig die Google Fonts runterladen, lokal zu cashen und auszuliefern. Das heißt, der erkennt in der Seite, die ausgegeben werden soll, welche Google Fonts da verwendet werden und vom Google Server eigentlich geladen werden, schmeißt das quasi im HTML-Code raus, lädt die Google Fonts lokal und bindet die dann ein, so dass man sich selber um nichts kümmern muss. Wenn, zumindest halbwegs sauber die Google Fonts eingebunden wurden. Auch da gibt es dummerweise Schwierigkeiten. Diese selbe Funktion hat das Erwaderv-Team eingebaut, muss man nur von CDN auf Local stellen und alles ist gut. Wenn man das Enfold-Theme nutzt, was ja einige tun, dann kann man da Custom Fonts hochladen. Dann kann man da einfach Google Fonts runterladen, da hochladen und die dann einbinden. Dann muss man die Google Fonts auch nicht nutzen. Aber man sollte nicht versuchen, Enfold mit diesem Self Hosted Google Fonts zusammenzunutzen. Das geht nicht. Weil Enfold ist toll. Enfold hat ein Datenschutz Funktionen drin, mit dem man Google Fonts generell abschalten kann in Enfold. Und damit das funktioniert, überprüfen die einen Cookie und machen irgendwelchen JavaScript-Coding erst in dem JavaScript Code laden sie die Fonts und weil sie da hier kein HTTPS oder HTTB vorschreiben, sondern das in dieser schönen kurzen Schreibweise machen, findet das Plugins Self Hosted Google Fonts, leider diesen Code nicht und kann ihn nicht ersetzen und deswegen bleibt das so drin und dann funktioniert es nicht. Das ist also ein bisschen doof, weil das keine schöne Lösung von Enfold ist an der Stelle. Aber nun gut. Es ist also ein bisschen tricky. Also die Standardlösung gibt es nicht. Man muss immer je nach verwendeten Plugins gucken. Also welprinz Plugins des Anbieters Thrive nutzt, der so Thrive Lead Pages und Thrive irgendwas. So, nächstes Thema Formulare und Kommentare, da können wir relativ flott durch, weil das ist relativ einfach. Formular sollte ein Hinweis haben, was mit den Daten geschieht. So, also Hinweis, nicht Checkbox, Hinweis. Nur Text, ob der so lang sein muss und wie heißen muss, ist vollkommen wurscht. Auch im Kommentarformular sollte man so einen Hinweis drin haben. Jeder, der ist sicher bewusst, dass er jetzt was abschickt, weil er will ja was abschicken. Aber den Hinweis dazu, dass man jetzt also und übrigens, wir speichern das, das schadet an der Stelle nicht. Ob das jetzt so 100 Prozent zwingend ist, kann man jetzt bestimmt drüber streiten und die Juristen werden da sicher das ein oder andere auslegen. Das ist aber eine ganz relativ gemütliche Variante, weitestgehend auf Nummer sicher zu gehen. Auch das klappt nicht bei jedem Team. Klar, logisch, wäre sonst langweilig, weil man diesen Filter kommen, Forms, die vor uns ein bisschen umbiegen muss und das, wenn das Team das selber schon unter Umständen getan hat, wenn ihr nach dem Wie klappt das nicht immer. Also alles super. Und bei den Kommentaren bitte noch dran denken, IP Adressen werden ja mitgespeichert. Die sind nicht zwingend notwendig dafür, dass ein Kommentar abgegeben wird. Also ist es irgendwas, was man eher nicht speichern sollte. Die kann man direkt löschen. Dass sie erst gar nicht gespeichert werden oder zeitversetzt. Zeitversetzt ist meistens das Argument dafür aus Gründen so IT-Sicherheit von wegen. Da kommt irgendjemand böses, kommentiert irgendwas Fieses und ich möchte noch die IP Adresse haben. Falls da irgendwelche rechtlichen Schritte kommen, damit ich nachweisen kann, wer das war und die IP Adressen noch habe, um irgendwas rechtlich gegen den Menschen vorzugehen. Deswegen gibt es Pluckens, die das erst nach 60 Tagen löschen. Da kann sich jeder selber überlegen, was er macht. Wenn man Block hat, wo man Kommentare sowieso immer manuell freischaltet, dann ist das etwas, wo man die IPs direkt löschen könnte. Weil man ja sowieso die Kontrolle hat, was online geht und was nicht. Grappatao and Imochis, meine Herren, wie habe ich noch viele Folien. Ist aber auch ein Thema. Gravatao, kennt ihr, das ist dieses Ding mit den Gesichtern, den Bildchen neben den Kommentaren und so. Um die Bilder anzuzeigen, wird die E-Mail Adresse genommen, gehäscht, in die USA am Server geschickt, der liefert ein Bild zurück, wenn es dazu ein Bild gibt. Merkt ihr selber, Server, USA. E-Mail Adresse zwar gehäscht, aber kann man ist reversibel und ja, so gespürzt. Meiner Meinung nach, deaktiviert man das, weil man das eigentlich braucht. Das ist kein Mensch, ja. Ich weiß, habe keine Ahnung, warum man das in irgendeiner Form braucht. Ich brauche es nicht. Wenn man die Kommentarfunktionen sowieso nicht braucht, kann man es erst recht abschalten. Geht ganz normal in den Einstellungen von WordPress. Gravatao kann man einfach deaktivieren. Wer es doch nutzen will, Plug-in, Avatar Privacy. Weil gibt es dann unter dem Kommentar, gibt es da so ein Display mal Gravatao Image next to my comments oder so ein Häkchen. Damit ist man schon mal eine Runde weiter. Natürlich muss man Gravatao dann in der Datenschutzerklärung erwähnen und dann kann man es nutzen. Oder wie gesagt, man lässt sein. Emojis ist auch so ein schönes Thema. Ihr kennt alle die Emojis. Moderne Browser nutzen die Emojis mit UTF-8. Das heißt, das Emoji ist ein Zeichen, was der Browser automatisch darstellt. Alte Browser nicht. Und damit auch Alte Browser Emojis haben, hat sich WordPress gedacht, dann bauen wir jetzt mal Emoji-Grafiken ein. Und die werden von dem WordPress-Server in den USA geladen und übertragen. Eure IP. Da ihr aber keine Einwilligung dazu habt, die IP-Adresse an den WordPress-Server in den USA zu übertragen und auch keinen Vertrag zur Auftragsverarbeitung mit dem hat, geht das nicht. Also ausbauen. Weil Alte Browser bedeutet E6 und so, die keinen UTF-8 Emoji-Supporter braucht sowieso kein Mensch ausbauen. Kann man mit einem Snippet machen, so 20 Zeilen Code oder Pluck in disable Emojis und die Dinger sind weg. Also wohlgemerkt nicht generell, sondern nur dieser Fallback für die Alte Browser. Der Rest funktioniert immer noch. Ich überziehe nur ein paar Minuten. Ich mach heute den Udo. Ja, eben. Irgendeiner muss ja unpinklich sein. Ja, eben. Dann gibt es so ein paar Pluckins, an denen man nicht sofort denkt, aber die so böse hintenrum noch irgendeinem was wollen. Jetpack zum Beispiel. Das ist sowieso ein Pluckin, was immer böse ist, meiner Meinung nach, aber ist egal. Also man möchte keinen Jetpack haben, aber wenn man es doch haben, sollte man ein paar Dinge bedenken. Es gibt in Jetpack eine Funktion zum Brute Force Lock in Schutz. Das ist eine Funktion. Da wird die IP-Adresse dessen, der sich einlockt an einen zentralen Server in den USA geschickt. Und dann guckt man danach, ob der das schon mal auf anderen WordPress-Seiten auch versucht hat. Und wenn das so ist, dann ist das bestimmt ein böser Junge. Und dann blockt man den nicht nach dem dritten, fünften, achten Versuch, sondern sofort. Jetzt kann man natürlich drüber streiten, weil es ja böser Junge Lock in Versuch und so, ob die IP-Adresse dann ist natürlich immer noch ein personenbezogenes Datum, wird aber in die USA geschickt, ob der Typ jetzt Rechte hat oder nicht, weil er meine Seite hacken will oder sich wieder rechtlich einlocken will. Trotzdem ist das zumindest eine kritische Funktion. Also besser abschalten. Ist sowieso Humbug, ist ein sicheres Passwort und fertig. Die Besucherstatistiken von Jetpack, die ja auf WordPress.com liegen, das suggeriert schon, die werden nach WordPress.com übertragen. Ist auch nicht schön, weil es quasi ähnlich wie Google Analytics, also es ist selbes Modell, müsst ihr all das selbe machen wie mit Google Analytics. Was ihr mit Jetpack aber bzw. WordPress.com nicht bekommt, ist ein Vertrag zur Auftragsverarbeitung. Zumindest ist nicht, wenn ihr nicht zahlender WordPress.com Nutzer seid. Und dann wird es schon wieder schwieriger. Also auch eher was, was man vielleicht eher sein lassen sollte, die Jetpack Statistiken zu nehmen. Und dann gibt es noch die Social Counts. Da sind wir wieder beim Social Sharing von der ersten Folie. Kleine Fältchen, wo ihr Share Links klicken könnt. Das sind Links. Das ist ganz ungefährlich. Daneben steht aber eine Zahl. Und die Zahl ist wie viele schon diesen Link geklickt haben. Und die wird live dynamisch von Facebook abgerufen über Jetpack und eure IP-Adresse da hingeschickt. Ja. Gut, das CDN von Jetpack würde ich sowieso nie nutzen. Weswegen ist es gar nicht aufgetaucht ist hier, weil das ist, na ja, egal. Also Jetpack ist an sich, merkt ihr, ist schwierig. Bei Sicherheitspluckins, bei anderen Sicherheitspluckins gibt diese Brute Force Lock-in-Schutz-System auch. Also bei WorldFans gibt es das bei-Themes Security, gibt es auch, also den Netzwerk Brute Force Lock-in-Schutz abschalten. Und dann gibt es natürlich noch die Protokollierung der IP-Adressen also in Security Locks, in Firewalls und so. Hab keine Lust mehr. Ich will die einfach behalten, weil ist ja Security. Könnt ihr sogar, weil habt ihr berechtigtes Interesse, IT-Sicherheit und so ist kein Problem. Aber halt auch nicht ewig, sondern eine gewisse Zeitspanne, also 30 Tage. 30 Tage vielleicht. Irgendwas halbwegs Brauchbares, wie man mal vielleicht zurückwärts noch mal gucken will, ob irgendwas passiert ist, alles danach muss gelöscht werden. Und wenn ihr ganz gut seid, wobei bei Security Locks kann man auch darüber streiten, sind die IP-Adressen natürlich in irgendeiner Form anonymisiert. Oder sie sind 30 Tage lang nicht anonymisiert und danach sind sie anonymisiert oder so was, ja. Wenn euer... Nö, ich höre nicht auf. Wenn euer Plug-in das nicht kann, ja, muss man mal gucken, ne. Also auch da sollte man auf jeden Fall drauf aufpassen. Und dann gibt es noch so lustige Plug-ins, mit denen man auch so ein Counter hat, so ein Like-Counter bei den Internen. Also der geht nicht zu Facebook, der geht nirgendwo hin, nur auf der Website selber, für die Website an sich. So, 20 Leute haben gesagt, oh, der Beitrag war aber schön. Was machen die IP-Adressen protokollieren, ja? Damit man nicht doppelt und dreifach liken kann und so. Ist auch ein bisschen blöd, ja. Und ich kenne eins dieser Plug-ins, das macht mit der vollen IP-Adresse dann eine Abfrage an einem Geolocation-Ding, um zu sagen, wo die Leute herkommen. Damit wird die IP-Adresse aber an ein Dritt-Server geschickt, ja? Und schon wieder ist das Problem da, ja? Ich liebe es. SSL-Verschlüsselung ist übrigens klar, ne? Da müssen wir nicht drüber reden. Ihr wisst, SSL-Verschlüsselung ist quasi Basis für die DSGVO, muss jeder haben. Punkt aus Ende, ne? Also alles, alles, ne? Reden wir nicht mehr drüber. Das Fiese ist, eure Website verschickt E-Mails. Und auch beim E-Mail-Versand sollte der Versand selbst verschlüsselt sein. Also nicht die E-Mail als solches. Der Inhalt muss jetzt keine verschlüsselte E-Mail sein, aber die Transport-Verschlüsselung beim Versenden sollte da sein. Und da WordPress aber mit PRP-Mail verschickt, ist das erst mal nicht so der Fall. Ihr solltet also über SMTP verschicken. Und dafür gibt es ein paar Plug-ins, mit denen man das relativ einfach einrichten kann, sollte die aber tun, ja? Also auch E-Mail-Versand, insbesondere bei einem Shop. Also in dem Augenblick, wo dann so irgendwie E-Mails mit Inhalten über hier Person X hat bestellt und so, per E-Mail rausgehen, ne? Spätestens dann solltet ihr auch das tun. Wenn du nicht Transport-Verschlüssel verschickst, ja. Das Ding ist halt, das muss ihr erst mal einer nachweisen, dass du das nicht tust, ne? Das ist vielleicht ein bisschen schwieriger, das zu beweisen, dass du das nicht tust. Aber wir reden ja über darüber, was du tun solltest, ne? Datenschutzerklärung ist klar, müsst ihr alle haben. Muss DSGVO-konform sein. Und der Standardanwender möchte keinen Anwalt fragen. Außer er kennt einen ganz gut, der vielleicht nebenher ein bisschen hilft. Aber ansonsten möchte der keinen Anwalt fragen, weil der Anwalt ist ja teuer. Also nehmen wir so einen Datenschutzgenerator. Ja, kann man machen. Und wenn du jetzt Dienstleister bist, dann sagt der Kunde auch, mach du da doch, ich hab da weiß nicht, weil ich da anklicken muss. Und sagt der Dienstleister, ja klar, mach ich. Ich weiß ja, was ich anklicken muss. Haftet denn jetzt der Dienstleister dafür, was er da geklickt hat? Weil ich meine, wenn da jetzt vergisst, die Google-Fonds anzuhaken, wenn da eine Google Maps drin ist. Und das steht in der Datenschutzerklärung nicht drin. Was passiert denn dann, ne? Ist also eine spannende Frage. Am Ende ist der Verantwortliche logischerweise der Betreiber der Seite, weil er ist der Verantwortliche, immer. Man könnte natürlich dann aber im Innenverhältnis sich überlegen, ob der nicht dann dem Web-Designer sagt, hier hör mal, da hast du aber falsch angeklickt. Im Außenverhältnis passiert das nicht. Er ist erstmal der Betreiber dran, aber im Innenverhältnis... Wow, und was passiert, wenn sich da irgendwas ändert? Und wenn der Generator sagt, oh, verdammt, mein Generator, ich hab ja mal eine neue Version vom Generator und überhaupt und sowieso. Und da ist man als Anbieter, vielleicht als Dienstleister, eher schwierig unterwegs. Und jetzt Achtung, letzte Folie. Noch vorm Mittagessen die letzte Folie. Also da an alle Dienstleister ein bisschen aufpassen, was er tut, ne? So von... Man darf ja auch keine Rechtsberatung geben, aber irgendwie muss man den Kunden ein bisschen an die Hand nehmen, aber auch nicht zu viel, weil nachher hat man selber ein Problem. Und der Vertrag zur Auftragsverarbeitung. Den vergessen die meisten. Sollte die aber haben. Und zwar mit dem Hoster. Weil, ist halt euer Hoster, da liegen die ganzen Daten. Also ich meine, wenn einer Auftragsdaten verarbeitet, dann wohl der Hoster, weil der hat ja alles, da liegen auf seinem Server. Der WordPress-Dienstleister, also so Typen, so wie ich, die Webseiten betreuen oder so. Die haben ja dauerhaften Zugriff auf alles, was da passiert. Also haben sie dieselben Daten, zumindest prinzipiell im Zugriff. Also die auch. Wenn die SEO-Agentur die ganze Zeit auf dem Server rumhüpft, hat die auch Zugriff auf die Daten. Also braucht man mit denen auch ein. Natürlich mit den Checking-Dienstleistern, Google Analytics und so. Das ist ja weitreichend bekannt. Und jedem Anbieter dessen, Inhalte als M-Bats eingefügt werden. Also so ohne Einwilligung, wenn man irgendwas machen will, dann braucht man das mit denen auch. Kriegt man aber nicht von denen. Also ist doof, deswegen Einwilligung ja. Das Entscheidende ist aber an der Stelle. Für mich jetzt zum Beispiel als Dienstleister, ist das vollkommen wurscht, ob mein Kunde einen hat oder nicht. Der Kunde, der Betreiber muss sich darum kümmern. Ich habe natürlich einen. Also wenn der Kunde kommt, da, sechs Seiten da, bitte unterschreiben. Danke. Aber ich habe nicht jeden Kunden angeschrieben. Das ist mir vollkommen egal. Wenn die sich nicht darum kümmern, das ist ihr Problem. Also der Kunde ist verantwortlich und muss sich darum kümmern. Auch Google Analytics sagt nicht jedem, hey, du nutzt das, unterschreib doch mal. Man ist vielleicht freundlich und sagt, denk dran, gibt's was. Aber der Dienstleister muss sich da nicht zwingend darum kümmern. Sollte was parat haben. Das hilft. Ich habe nur fünf Minuten überzogen. Das ist doch vollkommen okay. Gut, ich habe keine Fragen mehr zugelassen und ich bin durchgerannt wie blöde. Aber gut, ja, das war es. Die Fragen und Diskussion kürzen wir ab. Machen wir jetzt gleich daneben. Also ich bin ja noch hier den ganzen Tag, fragt mir Löcher in Bauch. Weil sonst kriegen wir hier den Raum nicht mehr gewechselt und die nächsten nicht mehr dran. Das machen wir alles, alles irgendwann gleich. Aber ihr dürft mich gerne den ganzen Tag mit allen Fragen nerven und ich schick euch dann auch sonst zu wem anders, wenn ich die Frage nicht beantworten kann. Ja, das war es. Danke.