DSGVO und RapidWeaver


(Kortschnoi) #1

Hallo Ihr!

Ich würde mich in diesem Thread gerne mit Euch zur neuen DSGVO austauschen, die Ende Mai in Kraft tritt. Nachdem ich mehrere Artikel zu dem Thema gelesen und ein Webinar mitgemacht habe, habe ich in Bezug auf meine Websites (die nahezu allesamt RW-Projekte sind) folgende Entscheidungen getroffen und Maßnahmen eingeleitet:

  1. Ich habe mit einem der Online-Generatoren eine DSGVO-konforme Datenschutzerklärung erstellt und lasse diese noch von meinem Anwalt prüfen.

  2. Bei meinem Webhoster habe ich eine aktualisierte Vorlage eines Auftragsdatenverarbeitungs-Vertrags (ADV) angefordert und warte auf Antwort. Seine derzeitige Vorlage scheint nicht DSGVO-konform zu sein.

  3. Im Webinar ist zur Sprache gekommen, dass der Einsatz von Google Fonts nach aktueller Einschätzung nicht DSGVO-konform hinzubekommen ist. Also habe ich die Google Fonts bis auf Weiteres aus meinen Themes rausgeworfen und setze derzeit auf Standardschriften. Überschriften in ausgefallenen Schriftarten setze ich als Grafik (SVG) ein.

Man kann Google Fonts auch lokal hosten, so dass nicht bei jedem Website-Aufruf Daten an Googles Server gesendet werden. Ich habe dieses GitHub-Projekt hier gefunden, bei Gelegenheit setze ich mich mal damit auseinander:

Mit Font Awesome verfahre ich ähnlich.

  1. Aus ähnlichen Gründen wie unter (3) verlinke ich nur noch auf YouTube-Videos, binde sie aber nicht mehr via iFrame ein.

Wie siehts bei Euch aus? Wie weit seid Ihr bei der Umstellung Eurer Projekte?

Ich freue mich auf Eure Antworten.

Beste Grüße
compukortschnoi


(Michael M.) #2

Wo ist das datenschutzrechtliche Problem der Einbindung von Google Webfonts, wenn du das in der Datenschutzerklärung genauso ausweist und auch von Google einen Vertrag zur Auftragsdatenverarbeitung geschlossen hast…? Wenn das tatsächlich so ist und man seine Projekte alle umbauen müsste, wäre das kaum bewältigbar. Ein erheblicher aktueller Vorlagen bindet Google Webfonts ein

Wenn Google Fonts nun ein Problem darstellen (sicher, man sie lokal einbinden), dann ist das nur die Spitze des Eisberg und das Problem trifft bei den aktuellen Vorlagen, speziell auch den CMS-Lösungen, die permanent irgendwas von irgendwelchen Bibliotheken laden zu. Warum dürfen Google Fonts nicht eingebunden werden, aber jQuery via CDN darf genutzt werden? Die Logik verstehe ich nicht ganz. Wenn das so durchgezogen wird, kannst du die Hälfte der interessanten Stacks rausschmeissen, weil sie irgendetwas von irgendwoher abfragen (und die wenigsten von uns wissen, was genau). Dann wird’s aber echt dünn. Dann können wir wieder die alten Classical Themes hervorholen und mit den alten Plugins arbeiten. Für die Fahrschulseite reicht es immerhin…

Ich denke, man muss im Moment einfach mal abwarten und darf nicht in blinden Aktionsmus verfallen - da ist zu viel unklar


(Jannis from inStacks Software) #3

Google hat dadurch, dass du Web Fonts einsetzt, doch keinen Zugang zu personenbezogenen Daten…


(Jan Fuellemann) #4

Doch, Google bekommt dadurch die IP-Adresse des Webseitenbesuchers. Bei eRecht24 im DSGVO-konformen Generator wird dies aber abgefangen, denn die Nutzung von Google Fonts ist ein berechtigtes Interesse des Webseitenbetreibers im Sinne einer einheitlichen Darstellung des Angebots (Art. 6 Abs. 1 lit. f DSGVO).


(Michael M.) #5

Wenn du die Diskussion bei eRecht24 im Mitgleiderbereich verfolgst, ist das nicht so eindeutig. Da ist schon die Rede davon, dass der Hinweis auf die Verwendung von Google Fonts verpflichtend ist (was soweit unstrittig ist), aber dann wird wieder davon geschrieben, dass du sie gar nicht einbinden darfst. Das ist schon alles ganz schön widersprüchlich

Wo hast du das her, dass der Hinweis das Problem entschärfen würde? Und was bedeutet „entschärfen“…?


(Jan Fuellemann) #6

Gute Fragen. Ich dachte bei “entschärfend” nur an diesen Generator. Nach dem Motto: wenn das dort so steht, dann haben sich die Anwälte dort schon eindeutig drum gekümmert… Ansonsten bin ich bei Dir: “Ich denke, man muss im Moment einfach mal abwarten und darf nicht in blinden Aktionsmus verfallen - da ist zu viel unklar”


(Michael M.) #7

Hier ein Kommentar von einem der Betreiber von eRecht24 - bezieht sich auf deine „entschärfende Lösung“

Ob man diese Verwendung über das „berechtigte Interesse“ der DSGVO legitimiert bekommt kann Ihnen ehrlicherweise im Moment noch niemand sagen. Einige Anwälte sagen so, einige Datenschützer so, die Gerichte dann im Einzellfall in 2 Jahren wohl wieder etwas anderes

Rechtssicherheit sieht anders aus


(Jan Fuellemann) #8

Dann lieber TypeKit nutzen, das sollte keine IP versenden. Ich habe da mal nachgefragt und mit ca. 100 Euro / Jahr sind die auch nicht so teuer. Oder ich hoste die Schriften selber - mit Foundry und dem Typeface stack sollte das auch gehen…


(Michael M.) #9

Das kann ich mir nicht vorstellen. Auch hier werden die Fonts vom Server nachgeladen (es sei denn du hostest sie selbst), dabei wird auch jeden Fall eine IP mitgeliefert.

Auch Selbsthosten ist nicht zwangsläufig die Ideallösung weil viele Lizenzen an Tracking gebunden sind. Linotype z.B. liefert dazu einen Code und immer wenn die Schrift beim Seitenaufruf vom eigenen (!) geladen wird, werden Daten an den Linotype-Server geschickt


(Oliver) #10

Hallo miteinander,

sehr interessant zu lesen. Wusste noch gar nicht, dass für die Datenschutzerklärung eine neue Verordnung kommt.

Zu einigen Sachen habe ich direkt auch eine Meinung (vorweggenommen, ich mach mir da keine Panik und lasse alles so, wie es ist).

Google könnte die Aufrufe seiner Fonts tracken. Ist allerdings sowieso egal, da jedem User bei Neuverbindung mit dem Internet eh eine neue IP zugewiesen wird (zumindest solange IPv4 noch on top ist). Selbst, wenn man die gleichbleibende IPv6-Adresse eines Users hätte ist diese Information ziemlich wertlos, weil der Endnutzer keinen Einfluss auf die Gestaltung einer Website hat und sich keine kommerziell nutzbaren Informationen daraus ableiten ließen. Aber gut, das ist im Zweifelsfall sowieso irrelevant.

Anbei, generell würde Google wohl auch eher die aufgerufenen CSS-Files tracken als die Fonts (diese liegen nämlich nur einen Tag im Chache, die Fonts hingegen ein Jahr). Folglich, wollt ihr auf Nummer sicher gehen, dann schraubt per .htaccess die Cachezeit der Google-Font-CSS-Files nach oben, sodass diese nicht täglich aufgerufen werden.

Wirklich von Bedeutung ist aber der Fakt, dass die Nutzung von Google Fonts ein One-Way-System ist. Da die API von den restlichen Google Services abgeschottet ist und sämtliche Leitungen über spezielle Domains laufen, werden weder Cookies gesetzt noch irgendwelche Daten gesendet. Habe spaßeshalber ne Sampleseite aufgesetzt und die Netzwerkanalyse + Waterfall im Auge behalten -> nur Downloads, keine Cookies, keine Uploads, nichts. Daher sind Fonts eine relativ cleane Sache. Und nochmal wegen der IP -> die ist derzeit immer noch dynamisch und muss zumindest innerhalb Europas sowieso anonymisiert werden, also datenschutzrechtlich meiner Ansicht nach relativ irrelevant. Selbst wenn man versucht, jemanden darüber zu orten, die Genauigkeit davon ist so grottig, dass das eigentlich nicht weiter zur Debatte stehen dürfte. Sollte ich dazu noch irgendwas außer Acht gelassen haben, lasse ich mich gerne aufklären.

Den einzigen Unterschied, den du damit erzielst, ist eine schlechtere UX für deine Besucher. Liegt daran, dass iFrames das so ziemlich undurchdringlichste sind, was es im ganzen Web gibt. Crawler können Seiten in iFrames nicht crawlen, Content-Anbieter können nicht feststellen, wer eine Seite gerade per iFrame aufruft. Alles was man feststellen kann, ist, ob man gerade per iFrame aufgerufen wurde oder nicht, und das auch nur mit JS. Und was dann? Man könnte versuchen, einen JS-Coockie zu setzen und darauf hoffen, dass der entsprechende Nutzer irgendwann auf die eigentlich Content-Seite zurückkehrt, um den Cookie dann auszulesen. Nur leider sind JS-Cookies ziemlich nutzlos und in der Anwendung ziemlich furchtbar, da man beim Auslesen genau wissen muss, wie der Cookie, den man auslesen will, überhaupt heißt, das System so aber nur auf die Ausgabe ALLER Cookies setzen kann, die dann erstmal auseinander klamüsert werden müssten…vom Client. Würde sowas wirklich betrieben werden, würde bei bspw. jedem YouTube-Aufruf das Browserfenster ne Zeit lang einfrieren, oder der Browser gleich im ganzen abschmieren.

Was FontAwesome, jQuery etc. angeht, haben wir prinzipiell den gleiche Fall wie mit den Fonts.
Wenn man da auch auf Nummer sicher gehen will, dann muss man die zwei Dateien halt manuell einbinden, ist nicht die Welt. Dann noch aus Stacks und dem Theme entfernen, fertig. Wer ganz besonders faul sein will kann sich auch eine Funktion mit php basteln, die die Inhalte aller Seiten einliest, alles was mit jQuery und/oder FA zu tun hat auslöschen lassen, dann die Verlinkung zum selbst gehorteten setzen lassen, speichern, fertig.

Bezüglich dem Webfonts-Helper auf GitHub…Warum? Es gibt dafür in RW deutlich angenehmere Lösungen zum Anwenden lokal gehosteter Fonts, bspw. diesen Custom Font Stack von Jannis oder das Teil von Joe Workman. Laufen 1A. Einmal Setup gemacht und in ein Partial gesteckt, fertig.

Mache ich nicht :slight_smile:

Ich persönlich bin zwar seit jeher ein Freund dessen, alle benötigten Fonts, Libraries oder whatever selbst zu hosten, aber ich bezweifle doch stark, dass man deshalb groß Panik schieben müsste. In der Datenschutzerklärung mal mit erwähnen, was von wo eingebunden wird und gut.

~N


(Jannis from inStacks Software) #11

Wie auch immer, scheint damit mein CustomFont Stack eine Neubelebung zu erfahren. Habe diesen damals auf Anraten von @apfelpuree entwickelt.
Werde demnächst mal ein gescheites Tutorial auch auf Deutsch schreiben und noch den ein oder anderen Text Stack mitliefern.

https://instacks.com/customfontstack/


(Oliver) #12

Ich persönlich verwende den in so ziemlich all meinen Projekten. Hauptsächlich vor allem, weil das der einzige Stack war/ist, der im alten Firefox zuverlässig die Fonts einbinden kann. (Muss man sich mal auf der Zunge zergehen lassen.) -> Es gab einige Sonderfälle, in denen der Firefox keine Fonts eingebunden hat, egal was man versucht hat. Mit deinem Stack gings dann plötzlich. Ich weis zwar nicht was du machst, aber mach weiter so :+1:


(Michael M.) #13

Mach doch gleich ein Demo-File, bei dem ein oder mehrere lokal gehostete Google-Fonts eingebunden sind


(T. R.) #14

Moin Jannis.

Bin gerade auf der Suche nach einem passenden Stack für mich eher zufällig über diesen Artikel gestolpert.

Kurze Frage dazu:
Wär es auch möglich, MyFonts-Schriften mit dem CustomFont-Stack relativ leicht zu integrieren?
(auf der verlinkten instacks-Seite ist ja von “… andere Web Font Anbieter…” die Rede.


(Jannis from inStacks Software) #15

Hallo, ich habe auf die Schnelle nicht gefunden, wie das bei MyFonts funktioniert. Tendenziell ja :+1: :wink:


(T. R.) #16

Ah, ok.
Danke für die schnelle Reaktion! :slight_smile:
… werd ich dann wohl mal bestellen und testen.

Ich hab z.B. für div. alte Schriften bisher immer einen Download-Ordner erhalten, den ich dann auf meinen “Domain-Server” hochgeladen habe und dann über “Schript/Code” die Schrift in meine RW-Projekte eingebunden habe …
Wär natürlich super, wenn ich dafür möglichst einfach z.B. das CustomFont-Stack nutzen könnte.

https://www.myfonts.com/info/webfonts/


(Michael M.) #17

Das müsste eigentlich problemlos gehen. Lediglich den Javascript-Code musst du noch im Code-Bereich unterbringen und den Lizenzvertrag auf dem Server ablegen (oder im Resources-Bereich). Zumindest ist das bei Linotype so


(Jannis from inStacks Software) #18

Falls man einen MyFonts Font kostenlos runterladen kann, kann ich mir das im Detail die Tage anschauen.


(T. R.) #19

Wow - das wäre natürlich wirklich supercool!

Ja, es gibt dort wohl einige … (muss man aber teils intensiv suchen … und dann teils auch nach Preis die Ergebnisse anzeigen lassen … meist steht dann dabei “some free”)

Aber auch ganz viele Webfonts bieten 30 Tage kostenloses testen (Botton “try these fonts on your own site” rechts oben in der Schrift-Prewview-Seite) … hier mal ein paar wahllose:
https://www.myfonts.com/fonts/font-fabric/mont/webfont_preview.html
https://www.myfonts.com/fonts/radomir-tinkov/gilroy/webfont_preview.html
https://www.myfonts.com/fonts/font-fabric/uni-neue/webfont_preview.html


#20

Das kann ja kompliziert werden mit den Google-Schriften, wenn es denn tatsächlich so kommen sollte.
In den Themes der verschiedenen Anbieter wimmelt es geradezu von Links zum Google-Schrift-Server.

Wenn ich solch ein Theme benutze,

  • müsste ich die Links in den CSS-Dateien löschen, auch wenn ich in meinem Projekt die Google-Font-Option nicht gewählt habe?
  • müsste ich die Links in den CSS-Dateien löschen, wenn ich die Google-Schriften auf meinem Server oder in den Recourses habe und sie von dort aus benutze, mal abgesehen davon, dass ich noch nicht weiß, wie ich das anstellen würde?

Irgendwie geht mir das alles schon etwas zu weit.

Jannis, wenn du eine Anleitung schreibst, dann bitte sehr ausführlich.