Firefox unter Linux – Cache reaktivieren nach Update auf Quantum

In bestimmten Testphasen von Weblösungen stelle ich mit Hilfe von Add-Ons oder auch über die in FF integrierten Developer-Tools öfter den Cache meines Lieblingsbrowsers Browsers ab. Im alten Firefox (etwa der unter Opensuse Leap 42.3 ausgelieferten FF-Version 52.8 ESR) gab es im Add-On "Web Developer" lange Zeit eine Möglichkeit zum dauerhaften Ab- und Anstellen des FF-Caches. Diese Möglichkeit bietet selbiges Add-On unter Quantum nicht mehr.

Bei einem Update auf Firefox Quantum unter Linux hatte sich die vorher gewählte Einstellung zur Deaktivierung des Caches im alten Firefox (Vers. 52.8, ESR) aber irgendwie verselbständigt:

Nach dem Update auf Quantum wurden keine Dateien mehr aus dem Cache gezogen - die Netzanalyse in den FF-eigenen Entwicklertools zeigte ein permanentes Nachladen aller Seitenelemente an. Das führt beim Wechseln zwischen den Seiten einer Web-Site, bei denen größere Hintergrundsbilder angezeigt werden, typischerweise zu spürbaren Verzögerungen und ggf. zu Flacker-Effekten. An diesen Effekten haben wir gemerkt, dass etwas nicht mehr stimmte.

Eigentlich wäre das auch OK - schließlich hatte ich die Einstellung ja selbst gewählt.
Irritierend ist aber, dass man in keinem Entwicklertool irgendwo eine Information zum dauerhaft deaktivierten Cache sehen würde. Mit den in FF integrierten Entwickler-Tools (unter dem Menü "Extras >> Web-Entwickler ..." findet man etwa im Bereich der "Netzwerkanalyse" eine Möglichkeit, den Cache temporär ab- und wieder anzuschalten. Eine Abschaltung für den gesamten Zeitraum, in dem man die Entwickler-Toolpalette nutzt, bietet auch der dortige Punkt "Werkzeugkasten-Einstellungen". Diese Einstellungen sind aber sitespezifisch wie temporär und verschwinden spätestens mit dem Schließen des FF-Developer-Werkzeugkastens.

Leider zeigten die genannten Werkzeuge nach dem Update auf Quantum nicht an, dass der Cache deaktiviert war. War er aber. Wegen der Einstellmöglichkeiten und der zuletzt getroffenen Wahl unter der alten FF-Version.

Die Behebung dieses Problems ist einfach, wenn man weiß, wo man zu suchen hat:

Man öffne die URL "about:config". Dort gibt man dann im Suchfeld den String "browser.cache.*.enable" ein. In meinem Fall ergab die Suche 5 verschiedene Einstell-Optionen:

browser.cache.disk.enable - browser.cache.disk.smart_size.enabled - browser.cache.memory.enable - browser.cache.offline.enable - browser.cache.offline.insecure.enable

Bei mir waren die Werte für "browser.cache.disk.enable" und "browser.cache.memory.enable" leider auf "false" gesetzt. Man stelle diese Werte auf "true" um - und schon funktioniert der FF-Cache wieder!

Für das temporäre Abschalten nutzt man die Optionen im FF-eigenen Entwickler-Werkzeugkasten. Mir reicht diese Möglichkeit zum temporären Abschalten in der Regel für das Testen von Webseiten.

Leider gibt es hier unter Quantum wohl noch Bugs: Die Kuchendiagramme des Punktes "Netzwerkanalyse starten" weisen bei vielen Seiten aus meiner Sicht fehlerhafterweise nicht aus, was unter Nutzung des Caches passieren würde. Angezeigt wird dort für bestimmte Sites "Antworten aus dem Cache:0". Obwohl die reguläre Darstellung der Downloadzeiten für die Seitenelemente mittels "Balkendiagrammen" die Nutzung des Caches mit korrekten Werten ausweist.

Dennoch viel Spaß weiterhin mit FF.

DSGVO, Datenschutz – und manche verdienen mit – ohne das Richtige zu leisten …

Meine Leser wissen, dass mir Datenschutz ziemlich wichtig ist. Aber manchmal könnte man sich die Haare raufen. Da gibt es endlich eine im Kern vernünftige Vorgabe des Gesetzgebers (nämlich die DSGVO) - und schon wird es von einer bestimmten Art von "Datenschützern" verdreht und missbraucht ...

So erlebe ich gerade bei einem Kunden, den wir vor einer Weile auf die DSGVO aufmerksam gemacht haben, eine Art panikartiges Verhalten - nicht durch den Kunden selbst, sondern durch dessen externen "Datenschutzbeauftragten". Es geht um die Erstellung von HTML-/CSS-Codes für statische Webseiten ohne Cookies - mit einer Ausnahme, nämlich Google Analytics. Das hatten/haben gar nicht wir zu verantworten. Vielmehr hat der Kunde auf einer Seite die Einbindung einer Google-Maps-Lagekarte gemäß der technischen Vorgaben von Google verlangt. Der Kunde hat einen klassischen Web-Hosting-Vertrag bei einem ISO 271001-zertifizierten Provider. Alles bestens. Wir erstellen Webseiten-Codes für statische (!) Seiten nach fachlicher Vorgabe und liefern die dem Kunden auftragsgemäß zu. Aus technischer Sicht ziemlich langweilig.

Nun sollen wir gemäß des besagten externen Datenschutzbeauftragten aber einen ADV-Vertrag (Auftragsdatenverarbeitungs-Vertrag) abschließen, weil "wir und nicht (!) der Provider die Web-Seite pflegen würden und durch die Webseite IP-Daten erfasst würden".

Da hat wohl jemand was in den falschen Hals bekommen. Leider erweist sich selbiger "Datenschutzbeauftragte" als beratungsresistent.

Ihr wisst schon - ADV-Verträge, das sind die Verträge, bei denen es um die Verarbeitung personenbezogener Daten durch Dienstleister im Auftrag eines Auftraggebers geht. Zielvorstellung von zugehörigen Musterverträgen ist (übrigens ganz im Sinne einer Lieferanten-Einbindung in Datenschutz und Security) die Erfassung der Datenart, der Kreis potentiell betroffener Personen, der Kritikalität der Daten, der Reichweite der Bearbeitungsschritte, etc.. Typischerweise werden zweifache Controller (einer auf AG- und einer auf AN-Seite) eingesetzt, Datenschutzbeauftragte benannt und technische Maßnahmen zum Schutz der Daten vereinbart. Pönalen werden für den Fall angedroht, dass der Auftragnehmer mit dem ihm überantworteten Daten Missbrauch betreiben sollte. Alles gut und richtig so.

Ziel der ganzen Geschichte sind in erster Linie Auftragnehmer, die sich für Auftraggeber mit elektronischen Diensten und deren Wartung/Pflege befassen müssen, bei denen z.B. Kundendaten, Bankdaten, Personaldaten etc. erfasst werden. In diesem Umfeld ist das auch alles völlig berechtigt. Das betrifft potentiell Pfleger von Web-Shops, manchmal aber auch Blogs, Personalabrechnungssysteme, Hosting-Provider, etc..

Worum aber geht es in unserem Fall?
Wir erstellen wie gesagt im Zuge von Einzelaufträgen statischen (!) HTML/CSS-Code für ein paar Webseiten nach Vorgaben des Kunden. (Ausnahme: Das kleine Google Analytics-Script für die Maps-Karte). Die einzigen "personenbezogenen Daten", mit denen wir dabei direkt zu tun hatten/haben, sind dabei die Daten, die im Handelsregister zur Firma veröffentlicht sind und auf den statischen Seiten wiedergegeben werden. Die Zulieferung der von uns erstellten HTML/CSS-Dateien kann von uns per Mail und zip-Datei erfolgen. Wir müssen die nicht mal auf die gehosteten Server hochladen. Mit dem Hosting-Vertrag unseres Kunden haben wir weiter nichts zu tun.

Nun hat der externe Datenschutzbeauftragte aber brav gelernt, dass der Hosting-Provider Zugriffsdaten bzgl. seiner Web-Server und auch bzgl. die Webseiten des Kunden erfasst - u.a. IP-Adressen der Besucher. Wie jeder Hosting-Betreiber halt, der einen ordentlichen Job macht. Wobei gerade der in diesem Fall relevante Provider erfasste IP-Adressen für seine Kunden nur begrenzt und nur verfälscht bereitstellt. Gelernt hat der "Datenschutzbeauftragte" auch, dass Google Analytics womöglich noch mehr Daten sammelt.

Wir haben den Datenschutzmenschen deswegen schon beim ersten Kontakt darauf aufmerksam gemacht, dass sein und unser Kunde deshalb (aber nicht nur deshalb; man denke etwa an die Mailaccounts) wohl einen ADV-Vertrag mit dem Webhosting-Provider und auch Google braucht. Und dass es entsprechende Hinweise und Erläuterungen in der zu erstellenden Datenschutzvereinbarung für die Web-Site unseres gemeinsamen Kunden geben muss.

Statt dessen will er aber nun einen ADV-Vertrag mit uns, weil ja wir die "Website pflegen würden". Das sei vom EuGH so geregelt. Und der gute Datenschutz-Mann bezieht sich dabei ausdrücklich auf die ggf. vom Provider und von Google Analytics erfassten IP-Adressen ....

Man fasst es ja nicht! Wir pflegen erstens gar nichts. Wir liefern beim Kunden HTML- und CSS-Code nach Vorgabe ab. Wir können zweitens auf die Elemente des Hosting-Vertrages, die Webserver und auf Log-Daten des Providers nicht zugreifen. Wir wollen das auch gar nicht. Wir haben auch keine Google Analytics Account für die Website unseres Kunden.

Und nun braucht es trotzdem wegen eines Web-Providers, zu dem wir nicht mal Zugang haben, und wegen von Google Analytics erhobenen IP-Adressen einen ADV-Vertrag mit uns? Wo wir von Google Analytics abraten?

Für diese Art von Wahnsinn und technischem Unverstand kann nicht mal Google etwas ...

Ich meine: Hier versuchen Leute mit der Not von Kunden in geradezu halsbrecherischer Weise Geld zu verdienen. Leute, die mich kennen, wissen, dass ein ADV-Vertrag mit mir eine fachlich und technisch ausgefeilte Sache werden würde, die sicher mehr als 15 Seiten Vertragstext erfordern würde. Wieviele Stunden würde der externe "Datenschutzbeauftragte" wohl für den Erstellungsmarathon zu welchem Satz abrechnen? Und welchen Sinn hätte im vorliegenden Fall ein solcher ADV-Vertrag für den Kunden?

Wir hätten ja verstanden, wenn der "Datenschutzbeauftragte" aus grundsätzlichen Erwägungen eine Verschlüsselung des künftigem E-Mail-Verkehrs mit unserem Kunden verlangt hätte. Bieten wir natürlich auf OpenPGP-Basis an. Und ggf. eine Lagerung von Vorgabetexten für kommende Webseiten in irgendwelchen Crypto-Containern, falls es denn dabei den jemals um hochsensible Firmeninformationen gegangen wäre. Was alles nicht der Fall ist. Aber nein - er will einen ADV-Vertrag mit uns wegen eines Providers, der nicht unserer ist, und Google Analytics, die IP-Adressen sammeln.

Übrigens: Zu den für den Kunden wirklich relevanten Dingen - nämlich dessen ADV-Verträge mit dem Provider, mit Google, ggf. Facebook haben wir noch nichts gehört. Und eine textliche Vorgabe für eine Datenschutzerklärung, für die wir dann eine statische Website erstellen müssten, wobei wir auch alle anderen Seiten wegen des zugehörigen Link neu generieren würden, haben wir noch nicht bekommen. Sind ja noch 10 Tage Zeit ...

Herr, bitte schmeiß mehr Hirn vom Himmel ... bitte gleich ... vor dem 25.05.2018!

Ein Einzelfall? Schreibt mir doch per Mail oder über Xing, wenn ihr gerade Ähnliches erlebt.

GnuPGP, email and eFail

Some of our clients use OpenPGP to communicate with us via mail. Now, after the last publications on eFail everybody gets nervous.

In general, some people out there - and hopefully not my clients - should indeed become nervous - if they use problematic email programs and/or handle them stupidly. In addition, there must be a chance of real and capable man-in-the-middle-attackers on the Internet - as e.g. secret or intelligence services - to perform and master the special attack vectors of eFail. (Actually, I do not care about the problems of bad guys out there misusing encryption for evil. I care about my business clients ...).

But, my dear clients: It is not the encryption mechanism of PGP or OpenPGP in itself which fails! It is partially the stupid default settings in some email programs (regarding HTML/Javascript-execution). Such settings can and should be be changed. And partially there are flaws regarding the structuring of emails which can be used against encrypted PGP mails.

But all of this can be mitigated by short term measures - and, astonishingly for myself, some basic rules coincide with what I am not getting tired to say to my clients:

  • Forbid HTML/Rich text in your email client programs. It is a source of evil. Never ever open HTML-parts of a mail. Do not click on Links. Forbid automatic loading of remote pictures and alike.
  • Install OpenPGP in your desktop environment and decrypt your messages in a non HTML-capable environment outside your eMail clients.
  • Use Kmail or Evolution with PGP.
  • And of course: Use Linux - where GnuPGP/OpenPGP comes along as basic equipment of most user environments and does not require fiddling with external programs as on (some) Windows systems.

Properly used PGP in its Opensource variants still is a secure way of exchanging emails. And, please, remember:

If your whole desktop or PC/laptop/server-environment is under attack and hacked no encryption will help you when you decrypt/encrypt in such an environment.

So: Do not panic. Be clear about what the real threats are and where they potentially may come from! Follow some simple basic rules. PGP-based encryption is only one brick in a secure exchange of information. Other bricks may be much more and directly vulnerable from the beginning.

Get more information here:
https://thehackernews.com/2018/05/efail-pgp-email-encryption.html
https://efail.de/
https://efail.de/efail-attack-paper.pdf
Bruce Schneier on Details on a New PGP Vulnerability

And by the way: There are other aspects of PGP which deserve some interest with respect to intelligence services and/or economic espionage:
https://motherboard.vice.com/en_us/article/ezpxan/pssst-your-pgp-is-leaking