Die (Kompromiss)-Lösung für das Google Font Problem von MBR 0 bis MBR 3

[Tommy Herrmann]

Ich denke es geht Mobirise, wegen der ganzen Abmahnungen, auch gerade in erster Linie um die im Thema "Mobirise3" verwendeten Schriften von Google-Fonts, die man sonst in diesen alten Themen nicht entfernen kann.

Hier meine Beispielseite mit dem neuen "Cookie Alert". Die Schriften - also die CSS - von Google Fonts wird nicht geladen, solange der Besucher den Datenschutzhinweisen im "Cookie Alert" nicht zugestimmt hat:

https://www.mobirise-tutorials.com/Test ... Testseite/

Aussehen tut es noch furchtbar, da sämtliche CSS blockiert wird - man kann aber den Layer vom "Cookie Alert" auf ganz dunkel oder auch auf schwarz stellen.

Um den "Cookie Alert" auf meiner Seite zu sehen, müsst ihr natürlich diesen Cookie mit dem Namen "CookiesDirective" von meiner Seite in eurem Browser löschen.

[Volker]

Da stellt sich nur die Frage, ob man damit wirklich vor Abmahnungen verschont bleibt.
Denn die Abmahnanwälte, bzw. deren "Mandanten" nutzen spezielle Crawler die nach dem Quelltext suchen und der wird ja auch trotz Sperre der CSS und Scripte angezeigt.

Fraglich ob Richter genug technisches Verständnis haben um das zu checken

Sicherer wäre es wenn der Quelltext Google Fonts frei ist, dann läuft der Crawler ins Leere und somit keine Abmahnung.

Ich hätte keine Lust das vor Gericht beweisen zu müssen, das keine Google Fonts geladen werden bevor man den Banner klickt.

Das nur mal meine Gedanken dazu

[Tommy Herrmann]

Ich glaube nicht, dass der Quellcode der Seite ausgeführt wird, was auch z.B. dieser "Google-Font-Checker" belegt:

https://sicher3.de/google-fonts-checker/

Wenn Du meine Testseite dort prüfen lässt - besteht diese die Prüfung erfolgreich:

Der Crawler läuft also ins Leere.

Du guckst ja in den Quelltext über den Browser, natürlich sind die Einträge nicht physisch auf meiner Seite gelöscht, diese werden nur nicht ausgeführt solange nicht zugestimmt wurde und darauf kommt es doch an. Niemand hat etwas gegen "Google Fonts" solange der Besucher dazu zustimmt.

Also kann auch meine IP nicht an Google gesendet werden.

Was anderes machen doch all diese Cookiebots, die heute fast jede Firma auf der Seite hat und wo man immer wählen muss welche Cookies man zulassen will und welche nicht - auch nicht. Da wird doch nichts im Quelltext gelöscht.

[Volker]

In meiner Abmahnung (4 Seiten) war eben ein Screenshot der Quelltext Inhalte als Anlage dabei.
Hab es mal eingescannt

Ich will das nur als Hinweis geben

[Tommy Herrmann]

Da gab es diesen neuen "Cookie Alert" von Mobirise doch noch gar nicht.

Genau darum geht es doch. Früher - wie bei Dir - gab es zwar das Fensterchen vom alten "Cookie Alert" aber im Hintergrund wurde die Seite bereits komplett geladen und ausgeführt - also auch "Google Fonts".

Der Besucher hatte also gar keine Gelegenheit "Google Fonts" zuzustimmen, da das längst ausgeführt wurde und seine IP bereits bei Google war.

Insofern ist die Abmahnung eigentlich gerechtfertigt.

Wir sprechen doch aber gerade über den neuen "Cookie Alert", den man nur gesehen haben kann, wenn man Mobirise v5.6.15 BETA, die es seit gestern gibt, bereits installiert hat (wie ich).

[Klaus]

Noch was zum Lesen ... ob das alles so stimmt?

https://dr-dsgvo.de/google-fonts-abmahn ... este-idee/
... und noch n paar Infos zu Cookie Tools ... ob das alte&neue Cookie Dings von MR was taugt?
https://dr-dsgvo.de/cookie-popups-darum ... sie-nicht/
https://dr-dsgvo.de/cookiegeddon-das-ve ... ent-tools/

[Tommy Herrmann]

nee - das von Mobirise taugt nicht wirklich was - aber eben eine Notlösung, die noch richtig getestet werden muss.

Diese "Cookiebot" APIs sind alle ziemlich teuer, denn da muss man immer auf deren Server das prüfen lassen und zahlt monatlich eine Gebühr, das können dann schnell mal 100,00 / Monat und mehr sein. Dann muss man dabei auch noch irre aufpassen, sonst machen die auch nichts anderes als ein sehr "wichtig aussehendes" Fensterchen.

[Dietmar]

Neue Idee das Fonts-Problem in MBR 0 bis MBR 3 datenschutzkonform einzubinden.

Zuvor gleich mal eine Antwort an KLAUS. Die Hinweise zu Dr-GSVO sind absolute spitze und haben mir nochmals zusätzlich die Augen geöffnet, dass man mit jeder Google Software, egal welcher, immer mit einem Bein vor Gericht steht. Man kann anscheinend nichts datenschutzkonform machen. Google ist immer irgendwie schneller. Dieser Dr. Klaus Meffert ist fachlich echt die Wucht!!!


So, nun aber zu meiner neuen Idee zur Elimierung des ätzenden MBR Font-Problems

- Diese Idee funktioniert garantiert. Ist mit 3 Scannern geprüft.

- Diese Idee ist hauptsächlich für kleine bis mittlere Projekte geeignet (denke ich mal), welche nicht mehr all zu oft aktualisiert werden.

- Es müssen nur 3 .CSS geändert werden. Das ist alles.

- Es muss in jeder Seite der Google-Font Pfad durch den lokalen Pfad ersetzt werden. Das ist alles.

Vorteil: Wenn nur ab und zu mal wenige Seiten in MBR geändert werden, muss danach nur noch der Google Font-Pfad geändert werden. Die geänderten .CSS-Dateien können auf dem Server unbehelligt bleiben.


Anleitung:

1.
assets/mobirise/mbr-additional.css

- Ganz oben in der Datei sollten alle Google Links bis auf einen einzigen Font entfernt werden und dann zwischen " " mit dem lokalen Fonts-Direktlink ersetzt werden.

Beispiel:
@import url(htt..://www.deine-domain.de/assets/fonts/Krub-Light/font.ttf);

- Dann alle Schriften im Code ersetzen durch eine einzige lokale Schrift vom Server

Beispiel hier mit dem lokalen Font Krub-Light im Ordner Krub-Light:
font-family: 'Roboto', sans-serif;
ändern durch lokalen Font auf Server in z.B.
font-family: 'Krub-Light', sans-serif;


2.
assets/mobirise/style.css
- Alle Schriften im Code ersetzen durch eine einzige lokale Schrift vom Server, wie obiges Beispiel


3.
assets/boostrap/css/bootstrap.min.css
- Alle Schriften im Code ersetzen durch eine einzige lokale Schrift vom Server, wie obiges Beispiel


4.
Font Code in den Seiten ändern
- In allen .html-Seiten muss der Original Google Font Link entfernt werden.
- Dieser muss durch einen lokalen Font mit einem Direktlink ersetzt werden.

Beispiel:
<link rel="stylesheet" href= htt..://fonts.googleapis.com/css family=Roboto:700,400&subset=cyrillic,latin,greek,vietnamese >
ersetzt z.B. durch
<link rel="stylesheet" href= htt..://www.deine-domain.de/assets/fonts/Krub-Light/font.ttf>


Wie oben geschrieben. Das Ergebnis ist bei allen 3 Font Checkern bestens, auch beim eRecht24-Checker. Alle 3 haben zum Ergebnis, dass die Fonts nun datenschutzkonform eingebunden sind!

Ich habe für das alte MBR 0 Projekt mit ca. 35 Seiten mit allem und mit Nachdenken nur ca. 1 1/2 Stunden benötigt, wobei die Fleißarbeit die Fontsänderungen in den .CSS war. Dies kann man zeitlich jedoch mit einer Textsuche gut verkürzen. Vor allem aber lassen sich bei gestalterischen Seitenänderungen die alten Fontscodes auf der Seite extrem schnell durch die geänderten auf dem Server oder auch dem PC ändern.

Ich hoffe, dies hilft so manchem Verzweifelten ganz konkret weiter. Ich werde nun weitere Alt-Projekte nach dieser Anleitung ändern.

Ich hoffe, dies hilft so manchem Verzweifelten ganz konkret weiter. Vor allem hilft dies SOFORT.

Einer Abmahnung betreffs Fonts kann damit wahrscheinlich vorgebeugt werden (keine Rechtsberatung).
Es bleibt nun viel mehr Zeit, um eventuell das komplette Projekt in aller Ruhe mit MBR5 zu erstellen.

[Dietmar]

Nachtrag: meine Alt-Projekt sind zuletzt mit MBR Version v4.12.4 bearbeitet und gesichert worden.

[Tommy Herrmann]

Moin Dietmar,

zunächst vielen Dank für Deinen riesen Einsatz bezüglich der Anpassung des alten Mobirise Design-Themas "Mobirise3" (oder noch älter).

Ich kann nur empfehlen, dann möglichst schnell vom alten Mobirise3-Thema auf das Mobirise5-Thema zu wechseln und die Seite neu zu bauen. Das ist und bleibt sonst Murks.

Mobirise wird und kann da nichts mehr ändern.

Der Neubau dürfte in den meisten Fällen relativ schnell gehen, denn man hat ja bereits sein Konzept, die Bilder und die Texte. Das alles lässt sich ja komfortabel in ein neues Mobirise5-Thema kopieren.

Ein Neubau bringt auch immer Vorteile bezüglich der Technik und meist auch des Designs und es wird mal aufgeräumt.

Ich habe das ja auch getan, nur hat es bei meinem Projekt mit ca. 45 Seiten schon lange gedauert, da ich einen Haufen komplizierter PHP-Anwendungen von unserem Werner Zenk, ausgerechnet in diesem alten Mobirise3-Projekt, eingebaut hatte auf die ich nun im neuen Projekt auf keinen Fall verzichten wollte.

Diese händische Fummelei, so wie von Dir vorgeschlagen, an den CSS- und Projektdateien vom Thema Mobirise3 macht eigentlich bald mehr Arbeit als ein Neubau und wird ja mit jeder neuen Publizierung vom Generator der Software wieder vernichtet.

Für mich wäre also Deine Lösung gar nicht denkbar, denn ich publiziere alle meine Projekte ständig neu, weil ich ständig Dinge ändere und sie auch ständig mit den neuesten Software-Updates versehe.

Man kann nur hoffen, dass unsere Gerichte dieser Abmahnwelle bald ein Ende setzen und diese Betrüger selbst mit harten Strafen wegen Rechtsmissbrauch der übelsten Sorte bestraft werden.

Übrigens die interaktive Karte von "Dr. DSGVO" habe ich schon vor einer ziemlich langen Zeit hier vorgestellt, mit Anleitung zum Einbau:

https://www.mobirise-tutorials.com/Test ... html#Karte

Vor kurzem habe ich auch noch die Karte von der "OpenStreetMap Foundation" direkt - ohne das Script von "Dr. DSGVO" - hier eingebaut:

https://www.mobirise-tutorials.com/OpenStreetMap.html

... aber mal ganz ehrlich, ob nun Google, Amazon, Apple, Microsoft, Samsung oder wer auch immer - sie alle greifen in gleicher oder vielleicht noch üblerer Weise unsere Daten ab, um diese zu Geld zu machen.

Woher soll ich z.B. wissen, was am Server von "OpenStreetMap Foundation" passiert (auch wenn das eine Stiftung ist), denn das JavaScript von "Dr. DSGVO" macht ja auch nichts anderes als die Karte im Skript abzufragen - also dann doch wieder zu einem anderen Server zu verlinken. Wieso die Anwälte das nun als rechtskonform bezeichnen, entzieht sich meiner Vorstellung. Woher wollen die denn wissen, was auf deren Server passiert?

Woher soll ich wissen was passiert, wenn ich mich bei irgendeiner Behörde einlogge oder zum Beispiel bei den städtischen Wasserwerken oder Müllabfuhr. Keine Ahnung, vielleicht treiben die den gleichen Datenmissbrauch.

Eine vollständige Prüfung und Kontrolle solcher Dinge ist für den "Normalbenutzer" vollkommen ausgeschlossen.

Wenn man den Gesetzen der DSGVO (Datenschutzgrundverordnung) uneingeschränkt Folge leisten wollte, dann müsste man auf das Internet komplett verzichten und auch gleich sein Handy in den Mülleimer werfen.

Diese ganze Verordnung kann man eigentlich nur in die Tonne treten und sie gehört überarbeitet. Gesetze werden leider sehr oft von Leuten, die wenig Ahnung davon haben, an der Wirklichkeit vorbei entwickelt. So einen Blödsinn kann es auch nur in Deutschland und Österreich vor Gericht geben.

[Dietmar]

Hallo Tommy,

ich bin in den allermeisten deiner Anmerkungen voll bei dir. Ja, ich denke auch, dass alle großen IT-Player mit ihrem Datenklau immer schneller sind, als es Cookie-Blocker je sein können (zumindest vorerst).


Zu meiner Anleitung: Ich habe ja Eingangs des Posts geschrieben, dass meine Idee eine schnelle Möglichkeit ist, wenn nicht mehr all zu viel übers Jahr geändert wird. Aber selbst bei mehreren Seiten geht das doch ganz gut und fix. Siehe meine 1 1/2 Stunden bei 35 Seiten - für die ERST-Komplett-Arbeit.

Bei den FOLGE-Arbeiten bzw. Seitenarbeiten geht das wirklich sehr fix:
- Die geänderten 3 .CSS bleiben ja auf dem Server. Unbehelligt. Da muss ich garnix mehr machen = 0-Arbeit.

- Bei neuen oder gestalterisch veränderten erstellen Seiten muss ich nur die Google-Fonts-Zeile/n austauschen. Das geht in Sekunden/Minuten. Das mache ich fix auf dem Server. Also auch kaum ein Aufwand. Ich finde, das ist so gut wie keine "Fummelei". Den entsprechenden Code für den lokalen Font habe ich in einer Datei auf dem Server abgespeichert und kann die ebenso fix jederzeit hervorholen. Ist alles in wenigen Sekunden gemacht.

Ach ja, diese "schnelle" Arbeit gilt natürlich nur bei händischem Upload der Seiten auf den Server, NICHT bei Nutzung des MBR-eigenen FTP-Upload-Generators. Bei Nutzung des Generators wird natürlich alles wieder überschrieben. Das kann dann nur mit händischem Upload umgangen werden. Aber auch dies geht ja total fix, in Sekunden.

Ganz klar, wenn man sehr oft Änderungen an seinem Alt-Projekt hat, dann kann das durchaus nerven und fummelig werden. Da gebe ich dir recht. Dennoch, es geht ja darum, SOFORT eine Lösung zu haben, damit man JETZT und gleich nicht mehr in die Abmahnfalle tappt und SOFORT aus dem Scanner-Focus ist. Datenschutzkonform. Vor allem ist die Realisierung meiner Idee wirklich sehr einfach, ohne großen Schwierigkeitsgrad.

Wenn ich z.B. meine 35 Seiten des Alt-Projektes JETZT ganz neu machen müsste, kämen mit Sucherei, Ausprobieren, SEO-Kram, wieder einen neuen Container suchen weil nämlich nicht alle in MBR5 funktionieren, eventuell doch wieder etwas ähnliches programmieren wie im Alt-Projekt, schätzungsweise aus meiner eigenen Erfahrung ca. 60-70 (80??) Stunden zusammen. Diese Zeit habe ich gerade im Moment nicht. Da waren dagegen die 1 1/2 Stunde für die ERST-Arbeit geradezu ein Minimal-Aufwand. Ich finde, das kann sich zeitlich sehen lassen.

Und wenn man dann noch weitere 5 eigene Alt-Projekte hat und weitere 2 alte Kunden-Projekte mit jeweils über 100 Seiten hat, dann kann man sich ganz leicht ausrechnen, wie viele Wochen man dafür veranschlagen müsste, um alle diese Projekte in MBR5 neu erstellen zu müssen. Und zwar SOFORT. Ehrlich gesagt, bei dieser Vorstellung sehe ich Herzrasen und schweißgebadete Hände.

Klaro, irgendwann im neuen Jahr werde ich dann langsam Projekt für Projekt ändern. Die gewonnene Zeit hierfür habe ich mir mit meiner Idee und wirklich sehr geringem Arbeitseinsatz nun dafür geschaffen. Muss ja niemand so machen.

[Dietmar]

Hallo Tommy,

super, der Hinweis auf deine Codes und Einbettungen für eine OpenStreet-Karte. Danke für die Veröffentlichung.
Anscheinend habe ich das in deinem Tutorial übersehen (Tomaten auf den Augen).

So etwas werde ich bestimmt demnächst umsetzen. Klasse! Danke für die Anleitung!

So schön die OpenStreet-Karten auch sind, Google Maps sind die besseren, auch grafisch besseren. Das ist so. Da kann ich jeden meiner Bekannten fragen. Dennoch, es wird Zeit den ganzen Google-Wahn und Google-Gebrauch zumindest ein klein wenig zu reduzieren.

[Volker]

Ich habe meine Seiten jetzt mit dem neuen Cookie Tool von der Beta Version versehen und muss sagen, das dies
sehr gut arbeitet. Auch wenn Tommy Probleme mit einigen seiner Seiten hatte, würde ich auf jeden Fall diesen Cookie Banner empfehlen.

Der DSGVO Checker von Dr.DSGVO ist einer der härtesten und findet nun keine Verstöße mehr.
Könnt ihr hier ja mal testen : https://dr-dsgvo.de/webseiten-check/

[Tommy Herrmann]

Volker,

hier Deine Seite, nicht alle wissen wo man die findet:

https://kfz-fotograf.de/

... ja - ich dachte auch erst, dass das eine gute Sache wäre - da werden aber nicht wirklich alle Skripte gesperrt, sondern nur "Google Fonts" - und diejenigen - die Mobirise selbst verwendet.

Dann hast Du genau die gleiche, schreckliche und nicht formatierte Darstellung der Seite, wenn Du z.B. den Browser-Cache löscht oder diesen mit Strg+F5 neu lädst.

Hier Deine Seite:

Wenn Du jetzt auf v5.6.13 zurück gehst, jedenfalls war das bei mir so (deswegen meine Warnung), bleibt diese Anzeige so - nein, sie erscheint sogar mit jedem Aufruf jeder der Seiten. Das ist ein nicht tragbarer Zustand.

Die verwendeten Booststrap-Klassen von meiner Seite, wie z.B. "Bootstrap Tooltip" konnten auch mit der Neuinstallation von v5.6.13 nicht wiederhergestellt werden.

Bevor ich so etwas schreibe teste ich das stundenlang.

Hätte ich keine Serversicherung gehabt, wäre mein Projekt jetzt verloren gewesen.

Das ist nicht tragbar.

[Volker]

Naja Tommy ist nicht ganz richtig das nur Google Fonts blockiert werden.

Das hier ist eine Kunden Seite :

https://www.campingrehmuehle.de/

Der wollte Maps unbedingt behalten wegen diverser Gründe. Auch Maps wird 100 % blockiert vor Aufruf, so wie alle anderen Tracker, Google Tools usw.

Hier der Test :

Meine Seiten:

www.360p.eu
www.immo-fotografen.de
www.niederastroth.de

[Tommy Herrmann]

Ich habe geschrieben - die von Mobirise verwendeten APIs also auch "Google Maps" werden blockiert. Andere - also selbst hinzugefügte - nicht zwangsläufig.

Im Moment geht es mir auch gar nicht mehr um das Blockieren irgendwelcher Dateien sondern darum, dass mir diese BETA-Version mein Projekt zerschossen hat.

Hätte ich kein Backup vom Server gemacht, wäre dieses Projekt jetzt verloren.

[Tommy Herrmann]

Lies mal:

https://forums.mobirise.com/discussion/ ... ent_103927

Diese Cookie-Alert-Änderung mit Skripten findet statt, wenn Sie Ihr Projekt veröffentlichen, das Projekt selbst wird nicht geändert. Cookie Alert in dieser Beta-Version funktioniert mit Skripten, die über Mobirise (Links) hinzugefügt wurden, aber noch nicht mit den Skripten, die über den Code-Editor hinzugefügt wurden. Ihr Tooltip-Skript verwendet also Bootstrap, das noch nicht verfügbar ist. Unsere Entwickler werden prüfen, was sie tun können.

Diese Cookie-Alert-Änderung mit Skripten findet statt, wenn Sie Ihr Projekt veröffentlichen, das Projekt selbst wird nicht geändert.

[Volker]

Ja Tommy ich lese überall mit und weiß das es noch eine Krücke ist.
Aber hier gehts ja um MR 3 und wie man sich da so gut wie möglich schützen kann.

Dafür scheint mir das Cookie Tool vorerst brauchbar. Ich habe es jetzt überall eingebaut und hoffe so auf ein wenig Ruhe in Bezug auf Abmahnungen. Sicher ist man eh nie zu 100 %. Aber mit dem Blockieren sind wir auf dem richtigen Weg finde ich.

Auch wer Maps unbedingt haben möchte ist so erstmal abgesichert ( wenn mit MR eingebaut )

[stobi_de]

Ich habe das mit Mobi3 und Google Fonts jetzt hier gemacht
https://www.bosch-service-schmidt.de/

Eigentlich genauso, wie in dem PDF beschrieben, aber dann mit MobiClean (komplexe Strings ersetzen) alle Links auf Schriften ersetzt.
Scheint soweit OK zu sein.
Auch Maps wurde durch Openstreetmap ersetzt - was allerdings wirklich ein Nachteil ist.

[Tommy Herrmann]

Na ja - das hatte ich auch beim Support bemängelt - da hast Du wohl nicht alles mitgelesen.

Wir hätten nun 3 unterschiedliche Optionen für den neuen "Cookie Alert", den auch ich im Prinzip als Notlösung für die alten "Mobirise3" Themen sehe.

Ein Cookie wird aber normalerweise per Domain gesetzt. Hat man nun z.B. (wie ich) alte "Mobirise3" Projekte, "Mobirise4" und "Mobirise5" Projekte auf der gleichen Domain - nur eben in Unterverzeichnissen - dann hat man den Salat bei allen Projekten.

Ich könnte nun als den einfachen Cookie bestätigen und den der sichere Cookie würde - durch den gleichen Cookie-Namen - gar nicht mehr abgefragt.

Man müsste also jeder dieser 3 Optionen nicht pro Domain verwenden sondern pro Projekt. So könnte dann auch ich z.B. nur mein "Mobirise3" Projekt schützen oder ein Projekt mit "Google Maps" und die anderen 80 Projekte außen vor lassen.