Ich bin seit Jahren ein treuer Firefox nutzer. Natürlich hat man in der Zeit auch mal andere Browser ausprobiert, daber die Freiheit die der Firefox Browser dem Nutzer gibt, ist sehr schön. Leider glänzt der Firefox in den letzten Wochen und Monaten eher mit Dingen, die man bei Microsoft bzw. Google erwarten würde:

Mozilla: Untergeschobenes Addon Search Shield Study

https://www.kuketz-blog.de/mozilla-untergeschobenes-addon-search-shield-study/

Heute morgen konnte ich erst festellen, dass der Firefox ungefragt das Addon Search Shield Study installiert und ungefragt eine Analyse durchführt. Nach einen Hinweis von mir, hat Mike Kuketz das Verhalten bestätigen können.

Firefox: Erfassung und Übermittlung der Surf-Aktivität

https://www.kuketz-blog.de/firefox-erfassung-und-uebermittlung-der-surf-aktivitaet/

In der neuen Firefox Version, die über die Webseite geladen werden kann, sind bei ca. 1- 2% der Nutzer ein Addon aktiv, das folgendes tut:

Das Experiment beinhaltet zudem das Datenerfassungstool, das Cliqz verwendet, um eine Grundlage für seine Empfehlungen zu schaffen. Die Surf-Aktivitäten derjenigen Nutzer, die eine Firefox-Version mit Cliqz erhalten, werden an die Cliqz-Server gesendet; darunter auch die URLs der Seiten, die sie besuchen. Cliqz verwendet verschiedene Verfahren, die dafür sorgen sollen, dass sensible Informationen aus den Surf-Daten entfernt werden, bevor diese aus Firefox versendet werden. Cliqz erstellt zudem keine Surf-Profile individueller Nutzer und löscht ihre IPs, sobald die Daten erhoben wurden. Der Code von Cliqz ist öffentlich zugänglich und eine Beschreibung der verwendeten Verfahren kann hier eingesehen werden.

Firefox: Screenshot Funktion

https://www.kuketz-blog.de/firefox-56-screenshot-funktion-deaktivieren/

Im aktuellen Firefox (Verison 56) ist eine neue Funktion mit der man Screenshots erstellen kann hinzugekommen. Der Nachteil, diese Screens werden in der Cloud abgelegt, wo nicht nur das hochladen getrackt wird, sondern auch jeder Aufruf.

Firefox IndexedDB Bug

https://www.kuketz-blog.de/firefox-das-alte-problem-mit-der-indexeddb/

Der Fehler ist bereits seit 8 Jahren bekannt, und trotzdem hat es Mozilla immer noch nicht geschafft oder will es nicht diesen Fehler zu beheben. Der DOM Storage wird nicht geleert, selbst, wenn man beim Löschen der Browserdaten alles auswählt. Diese Datenbank kann ausgelesen werden und ergibt so einen eindeutigen Fingerabdruck des Nutzers.

Ich vermute in den nächsten Wochen und Tagen wird noch mehr solcher Dinge auftauchen, die Frage ist jetzt ob der Firefox wirklich der richtige Browser für mich ist. Nur hier einen gute alternative zu finden, ist auch nicht leicht.

Achtung: In diesem Artikel sind fehlerhafte Informationen. Diese Artikel wird am 20.10 von mir gelöscht. Die Entsprechende Korrektur ist hier zu finden!!!

Ich bin seit Jahren ein treuer Firefox nutzer. Natürlich hat man in der Zeit auch mal andere Browser ausprobiert, daber die Freiheit die der Firefox Browser dem Nutzer gibt, ist sehr schön. Leider glänzt der Firefox in den letzten Wochen und Monaten eher mit Dingen, die man bei Microsoft bzw. Google erwarten würde:

Mozilla: Untergeschobenes Addon Search Shield Study

https://www.kuketz-blog.de/mozilla-untergeschobenes-addon-search-shield-study/

Heute morgen konnte ich erst festellen, dass der Firefox ungefragt das Addon Search Shield Study installiert und ungefragt eine Analyse durchführt. Nach einen Hinweis von mir, hat Mike Kuketz das Verhalten bestätigen können.

Firefox: Erfassung und Übermittlung der Surf-Aktivität

https://www.kuketz-blog.de/firefox-erfassung-und-uebermittlung-der-surf-aktivitaet/

In der neuen Firefox Version, die über die Webseite geladen werden kann, sind bei ca. 1- 2% der Nutzer ein Addon aktiv, das folgendes tut:

Das Experiment beinhaltet zudem das Datenerfassungstool, das Cliqz verwendet, um eine Grundlage für seine Empfehlungen zu schaffen. Die Surf-Aktivitäten derjenigen Nutzer, die eine Firefox-Version mit Cliqz erhalten, werden an die Cliqz-Server gesendet; darunter auch die URLs der Seiten, die sie besuchen. Cliqz verwendet verschiedene Verfahren, die dafür sorgen sollen, dass sensible Informationen aus den Surf-Daten entfernt werden, bevor diese aus Firefox versendet werden. Cliqz erstellt zudem keine Surf-Profile individueller Nutzer und löscht ihre IPs, sobald die Daten erhoben wurden. Der Code von Cliqz ist öffentlich zugänglich und eine Beschreibung der verwendeten Verfahren kann hier eingesehen werden.

Firefox: Screenshot Funktion

https://www.kuketz-blog.de/firefox-56-screenshot-funktion-deaktivieren/

Im aktuellen Firefox (Verison 56) ist eine neue Funktion mit der man Screenshots erstellen kann hinzugekommen. Der Nachteil, diese Screens werden in der Cloud abgelegt, wo nicht nur das hochladen getrackt wird, sondern auch jeder Aufruf.

Firefox IndexedDB Bug

https://www.kuketz-blog.de/firefox-das-alte-problem-mit-der-indexeddb/

Der Fehler ist bereits seit 8 Jahren bekannt, und trotzdem hat es Mozilla immer noch nicht geschafft oder will es nicht diesen Fehler zu beheben. Der DOM Storage wird nicht geleert, selbst, wenn man beim Löschen der Browserdaten alles auswählt. Diese Datenbank kann ausgelesen werden und ergibt so einen eindeutigen Fingerabdruck des Nutzers.

Ich vermute in den nächsten Wochen und Tagen wird noch mehr solcher Dinge auftauchen, die Frage ist jetzt ob der Firefox wirklich der richtige Browser für mich ist. Nur hier einen gute alternative zu finden, ist auch nicht leicht.

Bild: © fotodo / Fotolia.com

Dem Internetbrowser kommt im Bereich der Sicherheit im Internet eine zentrale Rolle zu. Speziell konfigurierte Browser wie das Tor Browser Bundle können die Privatsphäre stärken, unsicherer und/oder "gesprächige" Browser können gleichzeitig alle anderen Bemühungen konterkarieren. Leider sieht man am Beispiel Mozilla bzw. Firefox mal wieder, dass freie Softwareprojekte Datenschutz genau so mit Füßen treten können, wie kommerziellen Zwängen unterworfene IT-Konzerne.

Firefox war mal die große Hoffnung des freien Internets. Unabhängig entwickelt und vor allem durch Mundpropaganda verbreitet, beendete er die Monopolstellung des technisch rückständigen Internet Explorers, der aus den Browserkrieg der 1990er hervorgegangen war. In den letzten Jahren hat man jedoch massiv Marktanteile an Googles Chrome verloren. Das liegt natürlich einerseits an den hervorragenden Marketingmöglichkeiten, die sich Google durch seine Markmacht im Suchmaschinengeschäft bedienen kann, aber auch an der zeitweiligen technischen Überlegenheit. Chrome war einfach schneller, schlanker und stabiler als der aufgebläht wirkende, und behäbig entwickelte Firefox.

Chrome hat aber auch massive Nachteile. Kaum ein Browser überträgt so viele Nutzerdaten. Das liegt natürlich auch an der Geschäftsstruktur von Google, das mittelbar mit den Nutzerdaten Geld verdient, denn diese Daten sind die Grundlage zielgerichteter Werbung. Google hat deshalb nur ein geringes Interesse an spurenarmer Aktivität im Internet, wie sich kürzlich erst in der Reaktion auf Apples neue Sicherheitsvorkehrungen in Safari gezeigt hat.

Dies verweist bereits auf einen anderen Aspekt. Sofern man nicht in die großen Werbenetzwerke involviert ist, kann es durchaus lukrativ für ein Unternehmen sein, sich möglichst datenschutzfreundlich zu inszenieren. Apple macht das seit längerem verhältnismäßig erfolgreich vor, siehe z.B. das Verhalten in der FBI Affäre oder im Umgang mit der Auswertung von Nutzerdaten.

Es ist geradezu erbärmlich, dass ein kommerziell agierender IT-Gigant mit Sitz in den USA der Open Source Gemeinschaft vormacht, wie man von Datenschutz profitieren kann. Mozilla agiert nämlich im Angesicht sinkender Marktanteile und einer marginalen Bedeutung im mobilen Segment zunehmend erratisch. Mal versucht man sich datenschutzfreundlich zu geben, dann integriert man das proprietäre Pocket, sowie nun testweise Cliqz und ein weiteres Addons. Nachdem man Google schon bei der Versionierung kopiert und das Design nachgeahmt hat, möchte man wohl auch noch den Wettbewerb um die größte Datenhalde "gewinnen".

Zugegebenermaßen steht Mozilla nur sinnbildlich für weite Teile der Open Source-Landschaft. Anstatt die verhältnismäßig große Unabhängigkeit von Big Data-Sammelstellen zu nutzen und sich dezidiert als sichere Alternative zu präsentieren, haben viele Entwickler eine erstaunliche laissez-faire Einstellung zu dem Thema. Die exzessive Nutzung von Google+und ähnlichem zu Supportzwecken spricht da Bände. Man schreibt sich zwar Datenschutz und Sicherheit gerne auf die Fahne, aber außer allen Code offen zu legen, folgt dem nicht viel.

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht. Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That’s it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Nachdem ich im vorherigen Eintrag Hugo vorgestellt und ein Beispiel anhand des Quick-Start-Guides erklärt habe, möchte ich nun zeigen, wie ich quasi eine neue Seite online bringe.

Mein gesamtes Hugo-Projekt liegt dazu in einem Git-Repository. Es spielt keine Rolle, ob es sich dabei um Github oder Gitlab handelt.

Zur Zeit liegen die Website-Daten auf einem Webserver mit Plesk. Plesk bietet seit Version 17 oder 17.5 eine kostenlose Git-Extension, mit der Git-Repos geclont werden können. Und genau das werden wir nun tun.

In Plesk sollte eure Website bereits angelegt sein, stellt dort als erstes sicher, dass das Document-Root auf httpdocs/public umgestellt wird, da hugo, wie ja im ersten Beitrag erklärt, die fertigen Websiten-Dateien im public-Ordner speichert.

Wählt bei eurer Website nun das Git-Modul aus. Tragt als Remote Git repository die SSH-URL eures Repositories ein, speichert aber noch nicht.
Wie in meinem Screenshot zu sehen, wird Plesk von euch verlangern, den Public-SSH-Key in eurem Account bei Github zu speichern. Und genau das müsst vor Speichern auch durchführen. Den dazu gehörigen Menüpunkt findet ihr sowohl unter Gitlab als auch Github in euren Benutzereinstellungen.

Ist der Key hinterlegt, könnt ihr den Dialog abschließen, Plesk wird nun euer Repository clonen. Im besten Fall - wenn ihr alles richtig gemacht habt - sollte eure Seite nun sogar bereits dargestellt werden.

Nun möchte ich aber nicht ständig manuell ein git pull durchführen. Muss ich auch nicht, dazu behelfen wir uns mittels einen Webhooks. Github/Gitlab benachrichtigt somit Plesk bei Änderungen, die Änderungen im Git werden sofort aktualisiert. Das funktioniert wie folgt.

Wechselt in Plesk wieder in das Git-Modul eurer Website und öffnet die Repository Einstellungen. Dort findet ihr eine Webhook-URL, die ihr kopieren müsst.

In Githab/Gitlab müsst ihr diese nun einfügen. Dies ist beispielsweise bei Gitlab in den Repository Einstellungen im Unterpunkt Integrations zu finden. Wichtig ist hier, dass die Checkbox Push events aktiviert ist.

That's it. Zukünftig können weitere Änderungen einfach mittels Git commited und gepusht werden. Diese sind umgehend in Plesk verfügbar.

Die neue Web-Engine bringt den Firefox endlich wieder technisch auf Augenhöhe mit dem Chrome-Browser von Google. In den letzten Jahren ist der Martkanteil von Mozillas Browser immer weiter geschrumpft. Runderneuert könnte der Browser alte Fans zurückgewinnen.

Lange Zeit war der Mozilla Firefox die einzige ernsthafte Alternative zum Microsoft Internet Explorer. Für Webentwickler und Leute, die mit Linux arbeiten, war es die einzige vernünftige Option. Dann kam Google Chrome und hat den Markt aufgerollt – mit geballter Marktmacht des Suchmaschinen-Konzerns, aber auch mit überlegener Technik. Chrome ist einfach wahnsinnig schnell.

Für mich als Firefox-Fan wurde es immer schwieriger, einen Bogen um Chrome zu machen. Ich finde es aber nicht gut, wenn irgendwann jegliche digitalen Angebote nur noch von zwei bis drei Konzernen kommen. Firefox war immer noch eine sinnvolle, unabhängige und freie Alternative. Doch der technische Vorsprung von Chrome wurde in letzter Zeit immer offensichtlicher.

Im letzten Jahr kündigte Mozilla dann eine neue Web-Engine an. Die Web-Engine ist das Herz des Browsers und verantwortlich für die Geschwindigkeit, mit der Webseiten angezeigt werden. Doppelt so schnell und mit einem Drittel weniger Speicherverbrauch, will der Firefox ab dem 14. November 2017 auftrumpfen. In der Beta-Version kann man das bereits heute testen und mein erster Eindruck ist: Ja, der Firefox fühlt sich wesentlich flotter an.

Auch die Oberfläche wurde überarbeitet und sie sieht moderner aus. Auf der Startseite gibt es jetzt einige Link-Tipps von Pocket – dem Social Bookmarking Dienst, den Mozilla im Februar übernommen hat. Da wurden mir schon ein paar interessante Artikel angeboten.

Bisher habe ich Firefox-Sync noch nicht genutzt. Wenn man sich aber dort anmeldet, kann man nicht nur Bookmarks und Zugangsdaten zentral abspeichern und auf allen Geräten nutzen – man kann auch Tabs von einem an das andere Gerät schicken. Das ist praktisch.

Schon länger gefällt mir der Lesemodus sehr. Aus Seiten, die halbwegs ordentliches HTML haben, kann der Firefox eine Ansicht erzeugen, die gut zu lesen ist. Alle überflüssigen Elemente werden entfernt und die Schrift ist groß. Man hat dann reinen Text auf weißem Grund. So sind selbst Seiten, die noch nicht responsiv sind, kann man damit auf dem Smartphone gut lesen. Zusätzlich gibt es im Lesemodus eine Vorlesefunktion, die inzwischen auch gut zu verstehen ist.

Ich hoffe, dass der Firefox mit mehr Power auch wieder beliebter wird. Es muss ja am Ende nicht alles Microsoft und Google gehören.

Firefox wird endlich richtig flott

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS. Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht. Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen. Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS.
Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht.
Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen.
Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.

Bis zuletzt habe ich hier auf dieser Seite auf Ghost gesetzt, einem Blogsystem auf Basis von NodeJS.
Genauso wie Wordpress, schleppte auch Ghost einiges an zusätzlichen Funktionen mit, die man unter Umständen gar nicht benötigt, auch wenn das im Verhältnis zu Wordpress natürlich deutlich geringer ist.

Doch es muss nicht immer ein CMS sein. Gerade für Seiten, wie diese, auf denen sich hauptsächlich statischer Content, wie Text und Bilder befinden muss nicht unbedingt ein CMS genutzt werden.

Genau aus diesem Grund setze ich hier mittlerweile auf Hugo. Hugo ist ein Sitebuilder, geschrieben in Go für statische Seiten.

Texte, wie z.B. dieser werden in Markdown-Syntax geschrieben und veröffentlicht.
Der größte Vorteil ist neben der merkbaren Geschwindigkeit - es gibt halt kein träges CMS im Hintergrund - auch die gesteigerte Sicherheit. Es läuft kein PHP oder NodeJS. Reines HTML mit ein bisschen Javascript. Je weniger Angriffsfläche desto besser.

Anhand des Quick-Start-Guides sieht man, wie einfach Hugo sein kann. Unter macOS - Homebrew vorausgesetzt - läuft die initiale Installation/Einrichtung wie folgt:

brew install hugo
hugo new site quickstart

Somit hat man bereits hugo installiert (auf Github gibt es auch Pakete für Linux und Windows). Mittels new site-Befehl wird das Grundgerüst und alle benötigten Ordner für ein Projekt angelegt.

Im weiteren Schritt ergänzen wir ein Theme (es gibt wirklich viele und vor allem schöne!) und hinterlegen dieses in der config des Projektes.

cd quickstart;\
git init;\
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\

# Edit your config.toml configuration file
# and add the Ananke theme.
echo 'theme = "ananke"' >> config.toml

Anschließend wird noch ein erster Blogpost erstellt. Dieser findet sich anschließend im content-Verzeichnis wieder.

hugo new posts/my-first-post.md

Mittels Befehl hugo server -D lässt sich schlussendlich ein lokaler Webserver starten und die erstellte Seite lokal anschauen.
Passt alles, reicht ein einfacher Aufruf von hugo und die statischen Seiten werden im public-Verzeichnis angelegt.

Im folgenden Artikel zeige ich euch meinen derzeitigen Ablauf, wie ich Blogbeiträge schreibe, diese mit Git pushe und somit auf meinem Server ablege.

Im Rahmen seines Open Source Support-Programms („MOSS“) unterstützt Mozilla Open Source-Anwendungen finanziell. In der aktuellen Ausschüttungs-Runde hat Mozilla über 500.000 Dollar an Open Source-Projekte ausgeschüttet.

Mozilla hat die Initiative Mozilla Open Source Support, oder kurz: MOSS, Ende Oktober 2015 ins Leben gerufen und seit dem bereits mehrere Millionen Dollar an Open Source-Projekte ausgeschüttet. Die geförderten Projekte werden teilweise von Mozilla selbst eingesetzt, teilweise werden sie aber auch deswegen gefördert, weil sie mit der Mozilla-Mission konform gehen. Über alle Ausschüttungen kann hier mehr in Erfahrung gebracht werden.

Seit Mozillas letztem Update zum Thema Moss im April dieses Jahres hat Mozilla wieder mehr als 500.000 Dollar an Open Source-Projekte verteilt.

194.000 Dollar gehen dabei an Ushahidi, eine Open Source Crowdfunding-Plattform. 125.000 Dollar bekommt das Webpack-Projekt für die Entwicklung seines JavaScript Module Loaders. Die Förderung soll für die verbesserte Unterstützung von WebAssembly eingesetzt werden. RiseUp, eine Koordinations-Plattform, erhält 100.000 Dollar für die Verbesserung der Sicherheit des E-Mail-Services. 70.000 Dollar gehen an mod_md, eine Apache-Modul für ACME, um die Verwendung von HTTPS für Webseiten einfacher zu machen. Phaser ist eine HTML5-Spiele-Engine, welche 50.000 Dollar für die Fertigstellung der Entwicklung von Version 3 erhält.

Ein im Juni 2016 gestartetes Unterprojekt von MOSS ist Secure Open Source, oder kurz: SOS, mit dem Ziel, Open Source-Software sicherer zu machen. Dazu beauftragt Mozilla Sicherheits-Dienstleister, bekannte Open Source-Projekte hinsichtlich Sicherheits-Schwachstellen zu überprüfen.

In der Zwischenzeit hat Mozilla auch weitere Projekte auf Sicherheit überprüfen lassen, darunter den XML-Parser expat, den HTTP-Server libmicrohttpd sowie den NTP-Daemon chrony.

In expat konnten vier mittelschwere und drei schwache Sicherheitslücken gefunden werden, in libmicrohttpd eine mittelschwere und zwei schwache Sicherheitslücken, in chrony zwei schwache Sicherheitslücken.

Der Beitrag MOSS: erneut mehr als 500.000 Dollar von Mozilla für Open Source-Projekte erschien zuerst auf soeren-hentzschel.at.

Nach Firefox und Firefox Klar steht mit Firefox Rocket ein weiterer Browser für Android aus dem Hause Mozilla in den Startlöchern.

Auf Mozillas Support-Plattform SUMO (support.mozilla.org) ist mit Firefox Rocket die Hilfe zu einem weiteren Android-Browser von Mozilla nach Firefox und Firefox Klar erschienen. Eine kurze Recherche führt schließlich zu einem GitHub-Repository, welches das Projekt als „Emerging Market Experiment“ zusammenfasst. Zumindest derzeit zielt Firefox Rocket ausschließlich auf Indonesien ab.

Wie man es auch von Firefox und Firefox Klar kennt, begrüßt einen auch Firefox Rocket zunächst mit einer Einführungstour, welche einen Überblick über die Kern-Funktionen des Browsers liefert.

Die Einführungstour beginnt mit einem Hinweis darauf, dass Mozilla hinter Firefox Rocket steht und Firefox Rocket maßgeschneidert für Indonesien ist. Der zweite Bildschirm stellt den sogenannten Turbo-Modus vor, welcher Werbung und Tracker blockiert. Der dritte Bildschirm bezieht sich immer noch auf den Turbo-Modus und erklärt, dass das Blockieren von Werbung und Trackern nicht nur die Performance verbessert, sondern durch das Daten-Ersparnis auch Geld gespart wird. Durch das Blockieren von Bildern, einem weiteren Feature von Firefox Rocket, kann noch mehr gespart werden. Der vierte und letzte Bildschirm stellt schließlich die integrierte Screenshot-Funktion vor.

Der Startbildschirm von Firefox Rocket besteht aus einer Adressleiste sowie Kacheln von acht vordefinierten Webseiten. Neben Facebook und YouTube sind dies Seiten, die vermutlich in Indonesien populär sind. Auch das Menü ist hierüber zugänglich.

Über die Menü-Schaltfläche kann jederzeit mit nur einem Klick der Turbo-Modus oder das Blockieren von Bildern aktiviert respektive deaktiviert, der Browser-Cache geleert und auf die Chronik, Downloads oder Screenshots zugegriffen werden. Mittels integrierter Screenshot-Funktion lassen sich vollständige Webseiten-Aufnahmen machen, welche über den sichtbaren Bereich hinausgehen und auch dann zur Verfügung stehen, wenn gerade keine Internetverbindung besteht.

Übrigens: wie Firefox Klar vor Version 2.0 kennt Firefox Rocket kein Tab-Konzept.

Fazit: Firefox Rocket zielt ausdrücklich auf Entwicklungsländer ab. Mit Firefox hat Mozilla bereits einen sehr mächtigen Browser für Android im Angebot, Firefox Klar besitzt als spezialisierter Browser einen besonderen Fokus auf dem Schutz der Privatsphäre. Auch Firefox Rocket ist ein spezialisierter Browser, wobei der Schwerpunkt von Firefox Rocket auf dem Sparen von Daten liegt, was gerade in Entwicklungsländern auch mit dem Sparen von Geld gleichbedeutend sein kann.

Mozillas Gedanke dabei ist gut: statt mit Firefox nur auf ein Pferd zu setzen, kann Mozilla mit spezialisierten Browsern ganz gezielt Zielgruppen ansprechen, welche besondere Anforderungen haben.

Der Beitrag Getestet: Firefox Rocket, neuer Android-Browser von Mozilla erschien zuerst auf soeren-hentzschel.at.

Bisher war es auf meinem XMPP-Server nicht möglich das Passwort per Client zu ändern. Gerade wurde mir im prosody-eigenen MUC erklärt, warum das so ist: Es muss das Modul register aktiviert werden. Ich hatte das bisher nicht aktiviert, da ich keine In-Band Registrierungen (registrieren aus dem Client heraus) haben wollte und auch keine Webseite zum Registrieren aufgesetzt habe. Für die Familienmitglieder, die einen Account auf meinem Server haben, habe ich den Account per prosodyctl angelegt und sie selbst das Passwort eintippen lassen.

Zum Aktivieren von register muss im Bereich modules_enabled der Datei prosody.cfg.lua einfach register eingefügt werden:

        modules_enabled = {
            -- Other modules
            "register"; -- Enable mod_register
        }

Wer, wie ich, keine In-Band Registrierungen erlauben will muss noch in der Datei auch noch folgende Option setzen: allow_registration = false.

Bisher mussten Entwickler von Firefox-Erweiterungen eine Zeit lang warten, ehe ihre Updates für die Nutzer freigeschaltet worden sind. Dies gehört nun weitestgehend der Vergangenheit an: in Zukunft gibt es umgehende Freischaltungen für Firefox-Erweiterungen.

Mit den sogenannten WebExtensions hat Mozilla einen neuen Standard für Browser-Erweiterungen etabliert, welcher ab Firefox 57 verpflichtend für Erweiterungs-Entwickler ist. Da WebExtensions architekturbedingt sehr viel weniger anfällig für Sicherheits- oder Stabilitätsprobleme als die alten Erweiterungs-Architekturen sind, ergibt sich daraus ein weiterer Vorteil, den Mozilla nun aktiviert hat.

Bisher konnte es mehrere Tage und in schlechten Fällen sogar Wochen dauern, bis eine Erweiterung oder ein Update für eine bestehende Erweiterung freigeschaltet worden ist, da jedes Update vorher von einem Menschen manuell überprüft werden musste.

Ab sofort werden WebExtensions automatisch freigeschaltet und stehen damit bereits kurz nach dem Upload der neuen Version für alle Nutzer bereit. Menschliche Überprüfungen gibt es nach wie vor, so dass es theoretisch sein kann, dass eine Erweiterung oder ein Update einer Erweiterung nachträglich deaktiviert wird. Diese Überprüfungen werden anhand von Risiko-Faktoren priorisiert, welche unter anderem aus dem Code der Erweiterung und „anderen Metadaten“ kalkuliert werden, wie es in Mozillas Ankündigung heißt.

Für Nutzer von Firefox, aber auch für Entwickler von Firefox-Erweiterungen ist das eine großartige Neuerung, weil Änderungen an Firefox-Erweiterungen nun sehr viel schneller die Nutzer erreichen. Eine Änderung, welche mit den alten Erweiterungs-Architekturen nicht umsetzbar gewesen wäre. Auf der anderen Seite bedeutet diese Änderung, dass mehr Verantwortung als bisher bei den Erweiterungs-Entwicklern liegt, weil Gründe, die zur Ablehnung einer Version führen, nun unter Umständen erst nachträglich aufgedeckt werden. Entwickler müssen also vorher einen verstärkten Fokus auf die Einhaltung aller Richtlinien legen.

Der Beitrag Firefox: Keine Wartezeit mehr für Erweiterungs-Updates erschien zuerst auf soeren-hentzschel.at.