Archiv der Kategorie: Web

Wolkenhimmel

Nextcloud auf Shared Webhosting updaten

Das Betreiben einer Nextcloud-Instanz ist bei Hostpoint eigentlich nur geduldet und der Betrieb auf einem Shared Webhosting ist von Nextcloud auch nicht supported. Für den einfachen Datenaustausch betreibe ich aber trotzdem eine Instanz auf meinem Shared Webhosting und muss diese entsprechend auch immer mal wieder updaten. Dabei treten immer wieder dieselben Probleme auf, die ich hier mit den Workarounds dokumentieren will. Die Beschreibung ist auf dem Stand von Version 25, die Probleme traten aber identisch bei den Vorgängerversionen auf und ich vermute, dass sie auch bei den nachfolgenden Releases auftreten werden.

Ich verwende in dieser Beschreibung, da meine Nextcloud-Oberfläche auf Deutsch eingestellt ist, die deutschen Bezeichnungen.

0. Backup erstellen

Eigentlich sollte es jedem klar sein, dass bei einem Update immer etwas schief gehen kann. Aber nochmals zur Sicherheit: vor jedem Update Files und Datenbank sichern!

Um umfangreiche Verzeichnisse (wie z.B. eine Nextcloud-Installation) als einzelne Datei zu Sichern habe ich ein kleines php-Tool geschrieben, das auf Knopfdruck ein Backup startet und dann das .zip-File als Download zur Verfügung stellt.

Es empfiehlt sich zusätzlich die Datei core/shipped.json einzeln herunterzuladen, da wir diese im folgenden Ablauf noch ein paar Mal benötigen werden.

1. Update starten

Als Administrator das WebUI von Nextcloud starten. Falls in den Benachrichtigungen (Glocken-Symbol) auf das Update hingewiesen wird öffnet ein Klick auf den Hinweis die Verwaltungs-Seite, von welcher aus das Update gestartet werden kann. Ansonsten kann über das Benutzer-Menü oben rechts auf Administrationseinstellungen geklickt werden und es erscheint dieselbe Seite.

Unter „Version“ wird die aktuell verwendete Version angezeigt. Wenn eine neuere Version verfügbar ist wird diese unter „Aktualisieren“ aufgeführt. Dort befindet sich auch der Knopf „Updater öffnen“, mit dem die Update-Seite geöffnet wird.

Die Update-Seite ist auf Englisch, dementsprechend kommen hier die englischen Bezeichnungen zum Zug. Es wird nochmals die Ausgangs- und die Zielversion angezeigt.

Mit „Start update“ wird das Update ausgeführt.

Es werden die verschiedenen Schritte aufgeführt. Der aktuell laufende ist mir einem drehenden Kreis markiert während die erfolgreich durchgeführten Schritte mit einem grünen Haken markiert sind.

2. Delete old files

Nach einiger Zeit schlägt der Schritt „Delete old files“ fehl und ist mit einem roten „X“ und hellroter Hintergrundfarbe markiert. Leider liefert die Update-Seite keine Informationen, was genau schief gelaufen ist. Genauere Informationen findet man in der Datei data/updater.log. Dabei sind 2 Fälle zu unterscheiden, wobei es irgendwann von Fall 1 zu Fall 2 wechselt:

  1. Message: Could not rmdir:
    Es ist ein Fehler beim Löschen des nach rmdir angegebenen Verzeichnisses aufgetreten.
    Man könnte nun das Verzeichnis von Hand löschen, dies ist aber gar nicht nötig. Auf der Update-Seite ist anstelle des Buttons „Start update“ nun der Button „Retry update“ vorhanden. Dieser führt das Update an derselben Stelle weiter und versucht entsprechend nochmals das Verzeichnis zu löschen, was dann meistens auch klappt.
    Man muss nicht nach jedem Fehler im Log nachschauen was passiert ist, man kann auch einfach mehrmals auf „Gut Glück“ auf „Retry update“ klicken.
  2. Message: core/shipped.json is not available
    Spätestens wenn der Klick auf „Retry update“ augenblicklich wieder einen Fehler meldet sollte wieder das Log konsultiert werden. Wenn die obenstehende Meldung erscheint benötigen wir das einzeln gesicherte File. Dieses wird vermutlich beim Löschen der alten Dateien ebenfalls gelöscht, wird aber für den Retry-Mechanismus wieder benötigt.
    Entsprechend kopieren wir die Datei wieder an ihre ursprüngliche Stelle und starten dann wieder mit „Retry update“. Solange nun beim Schritt „Delete old Files“ ein Fehler auftritt müssen wir immer zuerst wieder die Datei core/shipped.json hochladen und dann wieder auf „Retry update“ klicken.
    Irgendwann wird auch der Ordner core gelöscht, dann muss entsprechend auch der Ordner wieder erstellt oder kopiert werden.

3. Move new files in place

Wenn wir beim Schritt „Move new files in place“ angekommen sind gibt es wieder Fehler der Art „Message: Could not rmdir“ (diesmal aber ohne : nach rmdir). Nun kann wiederum direkt auf „Retry update“ geklickt werden bis auch diese Fehlergruppe durchgearbeitet ist und wir beim Schritt „Continue with web based updater“ landen. Dort kann nun ber Button „Disable maintaince mode and …“ angeklickt werden und man landet bei der Aktualisierung der Apps.

4. Aktualisierung der Apps

Es werden alle Apps aufgeführt, die aktualisiert werden. Zuunterst gibt es den Knopf „Aktualisierung starten“ welche den Prozess auslöst.

Dies kann ebenfalls fehlschlagen, was zur Folge hat dass der Maintenance-Mode aktiv bleibt. Dadurch kann aber der fehlgeschlagene Schritt nicht nochmals gestartet werden.

In der Datei config/config.php muss ‚maintenance‘ auf false gesetzt werden um den Maintenace-Mode auszuschalten und den Aktualisierungsprozess weiterzuführen.

5. Abschluss

Zum Schluss sollte wieder das Nextcloud-Dashboard angezeigt werden. Der Maintenance-Mode wird dabei automatisch wieder ausgeschaltet. Auf der Verwaltungs-Seite (Benutzer-Menü oben rechts, Administrationseinstellungen) sollte nun unter „Aktualisieren“ vermerkt sein dass die Version aktuell ist. Falls dies nicht der Fall ist war man vermutlich auf auf einer älteren Major-Version und man darf das ganze Spiel (inkl. Backup!) nochmals durchführen.

HTTP-Header

Zusätzliche HTTP-Header definieren für statische Webseiten bei Webhoster

Verschiedene, teilweise sicherheitsrelevante Funktionalitäten können durch HTTP-Header aktiviert werden, so zum Beispiel die HTTP Strict Transport Security.

Wenn man eine dynamisch generierte Webseite (z.B. via php) hat kann man relativ einfach zusätzliche HTTP-Header definieren, die ausgeliefert werden sollen. Bei php kann dies z.B. mit der Funktion header() erreicht werden.

Bei statischen Webseiten gibt es diese Möglichkeit nicht. Oftmals hostet man solche Webseiten unter einem einfachen (shared) Hosting, für welches der Webhoster (in meinem Fall Hostpoint) oftmals in seiner Verwaltungsoberfläche keine Möglichkeit bietet die Header anzupassen.

Wenn die Webseiten mit dem Apache HTTP Server ausgeliefert werden und der Webhoster das Modul mod_headers aktiviert hat können über Einträge in der Datei .htaccess zusätzliche Header gesetzt werden.

Um zu überprüfen, ob der Mechanismus funktioniert kann ein Dummy-Header ausgegeben werden, der dann über die Entwicklerwerkzeuge des Browsers geprüft werden kann. Dies ist ungefährlich, da unbekannte Header vom Browser ignoriert werden. So kann z.B. folgende Zeile in der .htaccess-Datei im passenden Verzeichnis hinzugefügt werden:

Header add Test Debug

Dabei muss darauf geachtet werden, ob ein Bereich in der .htaccess-Datei für automatische Einträge durch die Verwaltungsoberfläche des Hosters reserviert ist. Falls die Datei noch nicht existiert kann sie mit der obigen Zeile als einzigem Inhalt neu erzeugt werden.

Wenn das Ganze erfolgreich war sollte im Antwort-Header eine Zeile mit folgendem Inhalt vorhanden sein:

Test: Debug

Wenn dies erfolgreich war kann der Test-Eintrag wieder gelöscht und der richtige Header definiert werden. Ansonsten sollte der Eintrag nochmals kontrolliert oder dann der Support des Hosters kontaktiert werden.

Aufgepretzelt – von statisch zu generiert – Teil 4

Pretzel

Pretzel

Mit Hilfe von Pretzel haben wir im dritten Teil die ersten redundanten Informationen ausgelagert. Im vierten und letzten Teil sehen wir, wie das Menü ausgelagert werden kann und was man bei Websites tun kann, die verschiedene Layouts verwenden.

Menü
Die meisten Websites bestehen aus mehr als einer Seite und nutzen zur Navigation zwischen den Seiten ein Menü. Um dem Benutzer anzuzeigen, wo er sich gerade befindet, wird der aktuelle Menüpunkt hervorgehoben. Dadurch sieht das Menü auf jeder Seite ein kleines bisschen anders aus, enthält aber immer die gleichen Menüpunkte, welche auch ausgelagert werden sollen.

Um das Menü mittels Pretzel auszulagern kann man den folgenden Aufbau im Layout benutzen:

<ul class="menu">
  <li {% if page.url == "/index.html" %} class="active"{% endif %}><a href="index.html">Home</a></li>
  <li {% if page.url == "/seite1.html" %} class="active"{% endif %}><a href="seite1.html">Seite 1</a></li>
  <li {% if page.url == "/seite2.html" %} class="active"{% endif %}><a href="seite2.html">Seite 2</a></li>
  <!-- etc. -->
</ul>

Dadurch wird bei der Seite, welche gerade bearbeitet wird (sprich, bei welcher die URL übereinstimmt) die css-class active gesetzt. Die Quelle für diese Variante ist Jekyll Tips. Dort wird auch auf den Nachteil dieser einfachen Lösung hingewiesen: Neue oder umbenannte Seiten müssen im Layout nachgeführt werden, sonst erscheinen sie im Menü nicht. Falls nur wenige Änderungen anfallen, kann dies aber verschmerzt werden. Die dort aufgeführte automatische Variante scheint mit Pretzel (noch) nicht zu funktionieren.

Zwei Layouts
Einige Websites nutzen neben dem Layout für die normalen Seiten ein zweites Layout, z.B. für den Blog oder eine Fotogalerie. Dazu kann ein weiteres Datei im Ordner _layouts erstellt werden. In den Dateien, welche das zweite Layout verwenden sollen, kann dann auf das neue Layout verwiesen werden.

Dadurch sind aber Redundanzen schon wieder vorprogrammiert. Dies kann aber durch includes verhindert werden. Die in beiden Layouts vorhandenen Fragmente können in Dateien ausgelagert werden, welche im Ordner _includes abgelegt werden müssen. Im Layout kann dann das Fragment mit {% include footer.html %} eingefügt werden.

Abschluss
Weitere individuelle Elemente sollten mit den oben gezeigten Grundlagen umgesetzt werden können. Ansonsten ist die Dokumentation von Jekyll eine gute Anlaufstelle, da die Beschreibung von Pretzel nur die Pretzel-spezifischen Informationen und die Unterschiede zu Jekyll enthält.

Sobald die Migration abgeschlossen ist können die geplanten Änderungen (welche ja der Auslöser für die ganze Arbeit waren) vorgenommen werden. Es empfiehlt sich dabei, den Mechanismus für die Sicherheitskopie beizubehalten.

Fazit
Mit diesen einfachen Grundlagen sollten die meisten Webseiten umgebaut werden können, so dass Änderungen einfacher vonstatten gehen. Gewisse Funktionen sind aber noch nicht komplett von Jekyll übernommen worden.

Aufgepretzelt – von statisch zu generiert – Teil 3

Pretzel

Pretzel

Nachdem wir im zweiten Teil die Struktur generiert und die Website ein erstes Mal generiert haben wollen wir nun vom Einsatz von Pretzel profitieren. Wir lagern redundante Informationen Schritt für Schritt zentral aus.

Jeder Durchgang besteht aus den drei Schritten identifizieren, modifizieren und kontrollieren.

Identifizieren
Als erstes müssen wir den HTML-Code der Seiten analysieren, um geeignete Teile zu finden, die zentral ausgelagert werden können. Dazu kommt das Compare-Tool zum Einsatz. Wir vergleichen dabei zwei verschiedene Seiten und suchen uns Blöcke, die identisch sind und auch thematisch sinnvoll ausgelagert werden können. Ein erster Kandidat ist dabei oftmals der Footer der Seiten. Wir können dies auch noch weiter überprüfen, indem wir weitere Seiten miteinander vergleichen.

Modifizieren
Wenn wir uns nun entschieden haben, können wir den auszulagernden Teil aus einer Datei kopieren, eine neue Datei layout.html im Ordner _layouts erstellen und den auszulagernden Inhalt dort einfügen. Dann müssen wir noch angeben, wo der individuelle Inhalt (der aus den verschiedenen Dateien kommt) eingefügt wird. Dies erfolgt durch den Platzhalter {{content}}. Entsprechend sollte dann die Datei layout.html folgende Struktur aufweisen, wenn der Footer ausgelagert wurde:

{{content}}
<!-- auszulagernder Footer -->

Damit nun die Seiten auch das Layout verwenden muss dies in jeder Datei angegeben werden (sogenannte Meta-Informationen). Dies geschieht durch folgenden Aufbau:

---
layout: layout
---
<!-- bisherige Seite, ohne Footer -->

Der Footer-Teil muss dabei auch bei jeder Datei entfernt werden, da er sonst doppelt erscheint.

Kontrollieren
Wenn wir alle Dateien entsprechend angepasst haben können wir Pretzel erneut mit dem Aufruf pretzel bake starten. Nachdem Pretzel seine Arbeit beendet hat können wir das Resultat im Ordner _site erneut mit der Ausgangs-Website vergleichen. Es sollten weiterhin keine Unterschiede vorhanden sein. Falls dies der Fall ist, sollte wiederum eine Sicherheitskopie angelegt werden.

Same same but different
Was aber ist zu tun, wenn auszulagernde Teile nur fast gleich sind, sich aber in kleinen, aber wichtigen Details unterscheiden? Dies tritt zum Beispiel oft beim Header der Seiten auf, die zwar dieselbe Struktur aber einen individuellen Titel haben.

Hierzu können in den Meta-Informationen Variablen definiert werden, auf welche im Template zurückgegriffen werden kann.

Eine Seite würde dann z.B. wie folgt aussehen:

---
layout: layout
title: Startseite
---
<!-- bisherige Seite, ohne Header und Footer -->

Das dazu passende Layout hätte folgenden Aufbau:

<!-- erster Teil des Headers -->
 <title>Meine tolle Website - {{ page.title }}</title>
<!-- zweiter Teil des Headers -->
{{content}}
<!-- auszulagernder Footer -->

Wiederum kontrollieren wir nach den Änderungen das Resultat und erstellen eine Sicherheitskopie.

Fehlerbehandlung
Bisher haben wir nur den Schönwetterfall betrachtet: Die Änderungen bewirken das gewünschte Resultat und wir können den nächsten Durchgang starten. Doch was können wir tun, wenn das Resultat nicht den Erwartungen entspricht?

Der einfachste Fall, aber manchmal trotzdem schwer zu erkennen, ist, wenn man beim Zugriff auf die Variablen einen Schreibfehler macht. So definiert man z.B. die Variable title (englische Schreibweise), versucht dann aber auf titel (deutsche Schreibweise) zuzugreifen. Eine nicht definierte Variable enthält dann einfach einen leeren Text, entsprechend wird auch nichts ausgegeben – leider auch kein Fehler.

Wenn man Fallunterscheidungen (mit if) oder Schleifen (mit for) verwendet kann es sinnvoll sein, den Wert einer Variablen einfach einmal auszugeben um so zu überprüfen, ob sie den erwarteten Inhalt hat. Dies kann man auch in einen HTML-Kommentar verpacken, um das Layout nicht zu stören:

<!-- DEBUG: URL der Seite: "{{ page.url }}" -->

Ausblick
Wir haben nun die ersten redundanten Informationen ausgelagert. Wie das Menü ausgelagert werden kann und was man bei Websites tun kann, die verschiedene Layouts verwenden, sehen wir im vierten und letzten Teil.

Aufgepretzelt – von statisch zu generiert – Teil 2

Pretzel

Pretzel

Nach den Grundlagen im ersten Teil erstellen wir nun die Struktur und lassen die Seiten aus den bestehenden statischen Seiten erzeugen. Dabei lagern wir aber noch keine Elemente in Templates aus.

Struktur erzeugen:

Pretzel wird über die Kommandozeile bedient, deshalb muss als erstes die Eingabeaufforderung oder die PowerShell geöffnet werden.

Mittels pretzel create kann die Struktur erzeugt werden. Diese wird im aktuellen Ordner erzeugt. Weitere Kommandos können über den Aufruf pretzel angesehen werden.

Die erzeugte Struktur gibt bereits eine Beispiel-Website mit einem Blog aus, wenn man sie generieren lässt. Da wir aber unsere bestehende Website migrieren wollen löschen wir die Beispiel-Dateien. Dies betrifft die Dateien about.md, atom.xml, index.html,rss.xml und sitemap.xml im Hauptverzeichnis sowie die Inhalte aller Ordner.

Dateien und Ordner mit bzw. ohne ‚_‘ am Anfang:

In der generierten Struktur fällt auf, dass es zwei unterschiedliche Arten von Dateien bzw. Ordnern gibt: solche mit und solche ohne ‚_‘ am Anfang.

Die Dateien und Ordner mit einem ‚_‘ am Anfang des Namens sind Hilfs-Dateien und -Ordner. Diese enthalten Informationen, die für die Generierung der Webseite zu Rate gezogen werden. So enthält die Datei _config.yml Konfigurationsdaten, welche die Generierung der gesamten Webseite beeinflussen. Der Ordner _layouts enthält Informationen, wie eine einzelne Seite aufgebaut werden soll.

Alle anderen Dateien und Ordner enthalten den Inhalt der Website und werden je nach Dateityp durch Pretzel verarbeitet (z.B. durch Informationen aus den Hilfs-Dateien angereichert) und das Resultat schlussendlich im Ordner _site abgelegt.

Website übernehmen:

Um die Website zu übernehmen kopieren wir die zu migrierende statische Website inklusive aller Unterordner und deren Inhalte in das Hauptverzeichnis. Mit dem Aufruf pretzel bake sollte dann das Unterverzeichnis _site entstehen, welches die generierte Website als Inhalt hat.

Mit Hilfe des Compare Tools können wir nun den Inhalt des Ordners _site mit der zu migrierenden Website verglichen werden. Wenn alles geklappt hat sollten keine Unterschiede festzustellen sein, da Pretzel nichts geändert sondern nur die Dateien übernommen hat.

Dies wäre jetzt der passende Zeitpunkt, um das erste Mal eine Sicherungskopie zu erstellen.

Ausblick:

Im dritten Teil werden wir die redundanten Informationen Schritt für Schritt zentral auslagern, um vom Einsatz von Pretzel profitieren zu können.

Aufgepretzelt – von statisch zu generiert – Teil 1

Pretzel

Pretzel

Es beginnt mit einer einzelnen, einfachen Web-Seite. Etwas HTML, etwas CSS, vielleicht auch noch ein bisschen Javascript. Dann kommt eine Zweite hinzu und mit der Dritten hält dann auch das Menü Einzug in die Website. Da dieses Menü in allen statischen Seiten vorhanden ist müssen dann beim Hinzufügen der vierten Seite alle anderen Seiten angepasst werden, damit alle das gleiche Menü haben.

Dann kommt der Gedanke: „Das muss doch einfacher gehen!“

Der Einsatz eines CMS (z.B. WordPress, Typo3, Silverstripe etc.) ist für ein paar wenige Seiten aber doch zu viel des Guten und es müssten dann auch regelmässig (Sicherheits-)Updates eingespielt werden.

Hier kommen die Website-Generatoren wie Jekyll, Hugo oder Pretzel zum Zug. Mit einem Website-Generator werden die Seiten lokal aus verschiedenen Dateien zusammengebaut. Die gesamte Website kann dann in der Form von statischen HTML-Dateien auf den Webserver hochgeladen werden.

Da in diesem Fall die Website schon besteht und vorerst keine Änderungen angebracht werden sollen beschreibe ich hier die Migration von statischen HTML-Seiten zu einer generierten Website. Dazu setze ich Pretzel ein, das Vorgehen kann aber für andere Website-Generatoren übernommen werden.

Voraussetzung:
Die HTML-Seiten sollten alle einen identischen, sauberen Aufbau haben. D.h. die einzelnen Seiten sollten sich nur in den relevanten Bereichen unterscheiden und es sollten z.B. keine fehlenden Menüeinträge auf einzelnen Seiten vorhanden sein.

Benötigte Software:

  • Website-Generator, in diesem Fall Pretzel in der Version V0.4.0.0.
  • Compare-Tool, um Dateien und Ordner zu vergleichen. Ich setze hierzu die Gratisversion von Code Compare ein. Als Alternative könnte z.B. Beyond Compare (ist kostenpflichtig) eingesetzt werden.
  • Die Dateien können zwar auch mit Notepad editiert werden, es empfiehlt sich aber ein komfortablerer Editor wie Notepad++ oder Visual Studio Code einzusetzen.

Ausserdem empfiehlt es sich, für die einzelnen Schritte des Umbaus Sicherungskopien anzulegen. Dies kann durch kopieren oder zippen des Arbeitsordners oder durch den Einsatz einer Versionskontrolle wie Git oder Subversion (SVN) erfolgen. Wenn man zur Versionskontrolle z.B. Github einsetzt hat man zudem noch eine Sicherungskopie ausser Haus.

Grundidee der Migration:
Am Ende der Migration möchten wir wieder dieselben Web-Seiten haben, die wir jetzt schon als statische Seiten haben. Dadurch sind wir sicher, dass der migrierte Webauftritt dem bisherigen Webauftritt entspricht. Sobald dies erfüllt ist können wir dann die gewünschten Änderungen vornehmen.

Dazu gehen wir Schritt für Schritt vor und ändern immer nur einen Aspekt, generieren dann die Website neu und vergleichen das Resultat mit den statischen Seiten. Wenn nun Unterschiede vorhanden sind analysieren wir, warum diese Unterschiede entstehen und passen unsere Änderung an. Sobald keine Unterschiede mehr ausgewiesen werden können wir eine Sicherungskopie anlegen und uns dem nächsten Aspekt widmen. Dies machen wir solange, bis alle nötigen Umbauarbeiten durchgeführt sind.

Ausblick:
Im nächsten Teil erstellen wir die Struktur und lassen die Seiten aus den bestehenden statischen Seiten erzeugen, ohne irgendwelche Elemente schon in Templates auszulagern.

Warum überhaupt verschlüsseln

Lock On Digital Screen

Image courtesy of jscreationzs at FreeDigitalPhotos.net


Wie ich in einem vorherigen Blog-Artikel beschrieben habe ist das Blog und die Webseite auch verschlüsselt erreichbar. Aber warum soll man meine Seiten überhaupt verschlüsselt besuchen?

  1. Zum eigenen Schutz
    Auch wenn man „nichts zu verbergen“ hat sollte man sich möglichst frei im Web bewegen können. Geheimdienste, Provider und weitere potentielle Lauscher können zwar auch bei verschlüsselten Seiten verfolgen, wer sich auf welchen Webauftritten aufhält (die sogenannten Verbindungs- oder Meta-Daten), erfahren aber nicht, welche einzelne Seite besucht wird. Es bleibt Dritten also z.B. verborgen, ob man die Blick-Webseite nur wegen der Sportnachrichten besucht oder andere Artikel liest.
  2. Zum Schutz anderer
    Journalisten, Anwälte, Whistleblower und andere sind darauf angewiesen, dass sie über das Internet geschützt kommunizieren können. Je grösser der Anteil des verschlüsselten Datenverkehrs ist, desto weniger fällt verschlüsselter Datenverkehr auf. Dadurch sind die Verbindungsdaten auch schwieriger zu filtern und auszuwerten.
    In diesem Zusammenhang möchte ich auch auf den lesenswerten (englischen) Artikel „Privacy Protects Bothersome People“ von Martin Fowler verweisen.

Beim Punkt „zum Schutz anderer“ kommt dann auch die Frage „wer sind denn alles ‚die anderen‘, die ich da schütze?“ Neben den oben erwähnten befinden sich darunter natürlich auch Kriminelle und Terroristen, welche die Verschlüsselung für die Planung ihrer Taten benutzen.

Dazu ein Zitat eines Tweets von Yehuda Katz:

The terrorists used encryption. LET’S BAN ENCRYPTION. The terrorists used guns. there’s no point in banning guns you can’t stop them anyway.
Yehuda Katz on twitter

Abschliessend gesagt: Ich empfehle jedem, Webseiten wenn möglich verschlüsselt zu besuchen.

Google-Alternativen beim Tages-Anzeiger

Der Tages-Anzeiger hat heute auch ein paar Alternativen zur Google-Suche vorgestellt.

Sie preisen diese auch als „solide Ersatzdienste, gerade für Datenschutz-sensible Nutzer.“ Was dann aber Bing in dieser Auflistung zu suchen hat ist mir schleierhaft, auch wenn in der Beschreibung darauf hingewiesen wird, dass Microsoft auch Daten sammelt.

Andere Suchmaschinen sollten aus meiner Sicht in diesem Zusammenhang eher erwähnt werden, z.B. Qwant, eTools.ch, MetaGer oder Unbubble.

Über die Gründe, warum man auch einmal auf Google verzichten sollte habe ich in meinem Blog-Artikel „Ente statt Krake – Suchmaschinen-Alternativen“ geschrieben.

Zugriff auf Web und Blog jetzt auch verschlüsselt möglich

FreeSSL!

FreeSSL! Initiative bei Hostpoint

Mein Hoster Hostpoint bietet seit Ende September mit FreeSSL Verschlüsselung mit jedem Hostingpaket an. Sowohl dieser Blog als auch meine Webseite sind dadurch nun auch verschlüsselt erreichbar.

Beim Publizieren des Angebotes hat Hostpoint aber noch Entwicklungspotential. Obwohl ich dem Kundendienst vor einiger Zeit eine Anfrage gestellt hatte, ob Verschlüsselung auch bei den ‚kleineren‘ Hostingpaketen möglich wäre und ich als Antwort erhielt, es sei etwas in Planung, musste ich aus den Medien von diesem neuen Angebot erfahren.

Ente statt Krake – Suchmaschinen-Alternativen

DuckDuckGo

DuckDuckGo Logo

Google weiss viel von uns. Wen wir kennen (GMail Kontakte, Google Plus), wann wir wen treffen (Google Calendar), wohin wir reisen (Google Maps), was wir suchen, z.B. weil wir etwas kaufen möchten (Google Search) und welche Seiten wir dabei besuchen (Google Analytics).

Das Problem

Bei der Suche passt Google die Resultate aufgrund unserer bisherigen Suchanfragen und unseres Surfverhaltens an. Google verkauft uns dies damit, dass es uns die für uns relevanten Resultate liefern will. Dies kann Google aber nur machen, indem es möglichst viel über uns weiss, sprich viele Daten über uns sammelt.
Neben der grossen Datensammlung über uns bekommen wir auch Suchresultate aus der Filterblase, dass heisst aufgrund unseres Surfverhaltens werden andere Meinungen in den Suchresultaten nach hinten geschoben. Dies kann z.B. bei Recherchen zu politischen Themen zu einseitiger Information führen.

Die Alternativen

DuckDuckGo.com verspricht eine Alternative zu sein. Die Suchbegriffe werden mit keinem Benutzer und auch keiner IP-Adresse verknüpft. Was gespeichert und was nicht gespeichert wird ist in der Privacy Policy detailliert beschrieben.
eTools.ch verspricht ebenfalls keine Daten zu speichern. Während DuckDuckGo neben anderen Quellen auch eigene Crawler benutzt arbeitet eTools als reine Metasuchmaschine, das heisst sie stellt die Suchanfragen (anonym) an andere Suchmaschinen (unter anderem auch DuckDuckGo) und stellt aus den Resultaten der verschiedenen Suchmaschinen eine eigene Resultatliste zusammen.
Beide Suchmaschinen empfehlen die Suche verschlüsselt zu verwenden, um das Mithören von Dritten zu verhindern oder zumindest zu erschweren. Auch bieten beide Dienste eine Android-App (DuckDuckGo Android App, eTools Android App) an, DuckDuckGo zudem auch Apps für iOS und BlackBerry (Android-App für BlackBerry 10).

Finanzierung

Beide Suchmaschinen blenden, wie Google, in den Suchresultaten Werbung ein um den Dienst zu finanzieren. Während Google aber alle möglichen gesammelten Daten verwendet benutzen DuckDuckGo und eTools nur die eingegebenen Suchbegriffe. Die Werbung wird dabei bei beiden Diensten klar gekennzeichnet.
DuckDuckGo gibt an, dass sie an den Affiliate-Programmen von eBay und Amazon teilnehmen. Das heisst, wenn man über die Suche von DuckDuckGo bei eBay bzw. Amazon das Produkt findet und kauft erhält DuckDuckGo eine kleine Provision.

Suchresultate

Google liefert nach meiner Erfahrung gerade bei Suchen im Bereich der Software-Entwicklung und des Web-Designs die für mich relevanteren Resultate, vermutlich da Google meine Anforderungen auch gut kennt. Um mich aber breit informieren zu können (z.B. politische Themen) vertraue ich eher anderen Suchmaschinen, die mich nicht so gut kennen bzw. zu kennen glauben.

Fazit

Bei der Suche gibt es, wie auch bei anderen Google-Diensten, Alternativen, man muss sie nur kennen und auch benutzen. Bei welchen Themen welche Suchmaschine die besten Resultate liefert muss aber jeder selber für sich herausfinden.