Bei der Verwendung des Tor-Netzwerks für ausgehenden Datenverkehr der Searx-Instanz besteht der Vorteil darin, dass die Suchmaschinen nicht immer die selbe IP-Adresse (z.B. von eurem VPS) sehen und somit keine Rückschlüsse wie „Ah, von der IP-Adresse kommen immer solche und solche Suchanfragen; das ist bestimmt die selbe Person“ ziehen können. Oder: „Ah! Diese IP-Adresse hat diesen PTR-Record (02.nmnd.de). Das ist dieser Kerl mit seinem Blog.“

Meiner Einschätzung nach wäre das schlimmer, als wenn man die Suchmaschinen direkt über ihre URL vom privaten Internetanschluss aus besucht. Dann sehen die Suchmaschinen zwar die IP-Adresse des Anschlusses, aber diese ist „von außen“ erst einmal keiner bestimmten Person zuordenbar. Wenn ich aber von meinem VPS – auf dem der Blog läuft und dessen IP-Adresse mit der Domain nerdmind.de in Verbindung steht – eine Suchanfrage tätige, dann ist das Mapping von IP-Adresse auf Person viel einfacher, als wenn ich mit meiner „anonymen“ Vodafone-IP unterwegs bin.

Andererseits wäre die Verwendung einer Searx-Instanz ohne Tor-Proxy pauschal aber immer noch besser, als die Suchmaschinen direkt im Webbrowser aufzurufen, wenn man das Problem des Browser-Fingerprintings bedenkt. Vermutlich wird der Nutzer eher automatisiert über Javascript und Tracking-URLs (wie z.B. bei Google) im Browser getrackt, als dass geguckt wird, ob die IP-Adresse zu einem VPS gehört und welche Domains diesem zugeordnet sind.

Es kommt also für die Entscheidung auf das „Threat-Model“ an, also gegen was man sich schützen möchte. Für mein Setup (Searx-Instanz auf VPS, dessen IP auf mich als Person schließen lässt) ist die Lösung mit dem Tor-Proxy ideal.

Das wären meine Überlegungen zu der Thematik. Falls ich da einen Denkfehler drin habe oder jemand noch Anregungen hat, kann er es mir gerne per Mail mitteilen. Nun geht es aber weiter mit der Anleitung!

Tor installieren und Searx-Konfiguration anpassen

Zur Installation des Tor-Clients muss unter Debian-artigen Linux-Distributionen lediglich das Paket tor installiert werden (wer möchte, kann vorher auch noch das eigene Package-Repository vom Tor-Projekt aktivieren):

sudo apt install tor

Der Tor-Dienst ist danach automatisch gestartet und aktiviert. An der Konfiguration von Tor muss nichts geändert werden, da Tor mit vernünftigen Standard-Einstellungen daherkommt. Standardmäßig startet der Tor-Dienst einen SOCKS5-Proxy auf localhost:9050, den wir nun in der Searx-Konfiguration (settings.yml) wie folgt ansprechen:

outgoing:
    proxies:
      http:
        - 'socks5h://localhost:9050'
      https:
        - 'socks5h://localhost:9050'
    extra_request_timeout: 5.0

Nun sollte der Datenverkehr zwischen Searx und den Suchmaschinen durch das Tor-Netzwerk fließen. In Ergänzung hierzu empfiehlt es sich noch, den Bilder-Proxy in der Searx-Konfiguration standardmäßig einzuschalten, damit auch die in den Suchergebnissen eingebundenen Bilder über die Searx-Instanz (und somit über Tor) geladen werden:

sed -i 's/image_proxy : False/image_proxy : True/' ~/settings.yml

Nachteile bei der Verwendung des Tor-Proxys

Ein Nachteil bei der Verwendung des Tor-Proxys ist, dass manche Suchmaschinen absichtlich oder unabsichtlich Tor-Exit-Nodes blockieren und die Searx-Instanz dann keine Ergebnisse von diesen Suchmaschinen zurückliefert. Daher ist hier noch ein bisschen Feintuning in den Einstellungen angesagt. Meine Konfiguration der Suchmaschinen sieht momentan wie folgt aus und liefert zuverlässig Ergebnisse (zumindest für die Kategorien „Allgemein“ und „Bilder“):

engines:
    - name: google
      disabled: True
    - name: yahoo
      disabled: False
    - name: qwant
      disabled: False
    - name: duckduckgo
      disabled: False
    - name: startpage
      disabled: False
    - name: reddit
      disabled: False
    - name: dictzone
      disabled: True
    - name: openverse
      disabled: True
    - name: qwant images
      disabled: False
    - name: library of congress
      disabled: True
    - name: duckduckgo images
      disabled: False

Schritt 1: Abhängigkeiten/Pakete installieren

Zur Installation des uWSGI-Servers müssen folgende Abhängigkeiten/Pakete installiert werden:

sudo apt install uwsgi uwsgi-plugin-python3

Schritt 2: uWSGI-Konfiguration erstellen

Nach der Installation des uWSGI-Servers muss eine neue Konfigurationsdatei für die Searx-Instanz mit nachfolgendem Inhalt im Verzeichnis /etc/uwsgi/apps-available/ erstellt werden. Ich benenne die Datei searx.ini:

[uwsgi]
uid = searx
gid = searx

processes = 20
workers = 4

env = LANG=C.UTF-8
env = LANGUAGE=C.UTF-8
env = LC_ALL=C.UTF-8
env = SEARX_SETTINGS_PATH=/opt/searx/settings.yml

chdir = /opt/searx/src/searx
virtualenv = /opt/searx/env
pythonpath = /opt/searx/src

disable-logging = true
enable-threads = true
single-interpreter = true
master = true
lazy-apps = true

module = searx.webapp
plugin = python3,http
cache2 = name=searxcache,items=2000,blocks=2000,blocksize=4096,bitmap=1
listen = 128 # Darf nicht größer als /proc/sys/net/core/somaxconn sein!

Schritt 3: uWSGI-Konfiguration aktivieren

Jetzt muss die soeben erstelle Konfigurationsdatei noch aktiviert werden. Dazu muss ein Symlink im Verzeichnis apps-enabled zur searx.ini im apps-available-Verzeichnis angelegt werden:

sudo ln -s ../apps-available/searx.ini /etc/uwsgi/apps-enabled

Danach kann der uWSGI-Daemon wie folgt neu gestartet und die Logdatei beobachtet werden:

sudo systemctl restart uwsgi & sudo tail -fn0 --retry /var/log/uwsgi/app/searx.log

Wenn alle Schritte erfolgreich durchgeführt wurden und es keine Fehlermeldungen in der Logdatei hagelt, kann der Webserver konfiguriert werden. Nachfolgend zwei Beispiele für die Platzhirschen Apache und nginx.

Schritt 4: Webserver als Reverse-Proxy konfigurieren

Der uWSGI-Daemon erzeugt standardmäßig das UNIX-Socket /run/uwsgi/app/searx/socket für die Searx-App. Auf dieses können wir nun von unserem Webserver aus zugreifen. Die folgenden Beispiele sind Minimal-Konfigurationen für Apache und nginx, die von euch noch angepasst werden müssen (TLS, Basic-Authentication, usw.).

Hinweis: Für die Verwendung von Apache muss zuerst noch das uWSGI-Proxy-Modul installiert und anschließend die beiden Module proxy und proxy_uwsgi über a2enmod in der Apache-Konfiguration aktiviert werden:

sudo apt install libapache2-mod-proxy-uwsgi
sudo a2enmod proxy proxy_uwsgi

Hinweis: Um die Searx-Instanz über eine Sub-URL verfügbar zu machen, bitte zusätzlich Schritt 5 befolgen!

Beispiel: Virtualhost-Konfiguration für Apache

<VirtualHost *:80>
	ServerName sx.example.org

	ProxyPass /static/ !
	ProxyPass / unix:/run/uwsgi/app/searx/socket|uwsgi://localhost

	Alias /static/ /opt/searx/src/searx/static/

	<Location /static/>
		Require all granted
	</Location>
</VirtualHost>

Beispiel: Virtualhost-Konfiguration für nginx

server {
	listen [::]:80 ipv6only=off;
	server_name sx.example.org;

	location / {
		include uwsgi_params;
		uwsgi_pass unix:/run/uwsgi/app/searx/socket;
	}

	location /static/ {
		alias /opt/searx/src/searx/static/;
	}
}

Schritt 5: Searx-Instanz über Sub-URL verfügbar machen (optional)

Falls man die Searx-Instanz nicht im Wurzelverzeichnis (/), sondern einem Unterverzeichnis (/custom/) erreichbar machen möchte, muss in der Searx-Konfigurationsdatei die Option server.base_url angepasst werden:

sed -i 's#base_url : False#base_url : "/custom/"#' ~searx/settings.yml

Außerdem müssen noch die Pfade in den Virtualhost-Konfigurationen angepasst werden:

Änderungen für Apache-Konfiguration

sed -i 's#ProxyPass /#ProxyPass /custom/#' apache-vhost.conf
sed -i 's#/static/#/custom/static/#' apache-vhost.conf

Änderungen für nginx-Konfiguration

sed -i 's#location /#location /custom/#' nginx-vhost.conf

Fertig!

Nachdem der Webserver und uWSGI-Daemon neu gestartet wurde, sollte alles wie erhofft funktionieren.

Im Gegensatz zu einer selbstgehosteten P2P-Suchmaschine wie Yacy crawlt Searx nicht selbst das Web und baut auch keinen eigenen Index auf Peer-to-Peer-Basis auf, sondern leitet die Suchanfragen des Benutzers einfach nur – wie oben beschrieben – an die vorher eingestellten Suchmaschinen weiter und bezieht von dort die Ergebnisse.

Ein Vorteil ist, dass die Links aus den Ergebnissen von z.B. Google keine Tracking-Parameter mehr enthalten, mit denen Google bei direkter Verwendung ihrer Suchmaschine im Webbrowser über JavaScript normalerweise jeden Klick auf ein Suchergebnis trackt. Anstatt dass der Webbrowser des Benutzers die Suchanfrage direkt an die Suchmaschine sendet, fungiert Searx hier als Proxy und sorgt dafür, dass auch keine Cookies mitgeschickt bzw. gespeichert werden.

Ein weiterer Vorteil ist, dass mehrere Benutzer die selbe Instanz verwenden können und eine Suchanfrage so aus Sicht der einzelnen Suchmaschinen nicht mehr so einfach einem bestimmten Nutzer zugeordnet werden kann.

Obwohl man durch die Benutzung einer selbstgehosteten Searx-Instanz schon einen großen Schritt in Richtung mehr Kontrolle über seine Daten erzielt hat, sehen die Suchmaschinen allerdings immer noch die IP-Adresse von dem Host, auf dem Searx installiert ist. Sollte man sich also dafür entscheiden, seine Searx-Instanz ausschließlich selbst zu nutzen und nicht mit einer Gruppe an Nutzern zu teilen, ist es empfehlenswert, den Datenverkehr zwischen der Searx-Instanz und den einzelnen Suchmaschinen zum Beispiel via SOCKS-Proxy durch das Tor-Netzwerk zu leiten.

In diesem Beitrag wird gezeigt, wie man eine Searx-Instanz zur Eigennutzung auf einem Debian-artigen Linux-System installieren und ausgiebig testen kann. Verzichten werde ich auf die Einrichtung von Filtron, einem Reverse-Proxy mit Filterregeln, der für den Betrieb öffentlicher Instanzen gedacht ist und unter anderem verhindern soll, dass zu viele Suchanfragen an die Suchmaschinen gestellt werden, was eine Blockierung der Searx-Instanz zur Folge haben kann.

In einem weiteren Beitrag wird gezeigt, wie man die Searx-Instanz für den Produktiveinsatz einrichtet und diese über den uWSGI-Daemon mit einem WSGI-Proxy-fähigen Webserver (Apache, nginx, ...) als Reverse-Proxy verbindet.

Schritt 1: Abhängigkeiten/Pakete installieren

Vor der Installation von Searx müssen folgende Abhängigkeiten/Pakete installiert werden:

sudo apt install python3-dev python3-babel python3-venv git build-essential libxslt-dev zlib1g-dev libffi-dev libssl-dev shellcheck

Schritt 2: Neuen Benutzer für Searx erstellen

Nachdem alle Abhängigkeiten installiert wurden, erstellt ihr einen neuen Benutzer, unter dem Searx ausgeführt werden soll. Ich nenne den Benutzer searx und nehme als Home-Verzeichnis /opt/searx. Als Login-Shell nehme ich Bash, damit wir uns für die Installation (und später für Debugging/Wartung) ganz normal mit su - searx einloggen, in das virtuelenv wechseln und die Searx-Instanz ohne uWSGI starten können.

sudo useradd --system --home-dir /opt/searx --shell /usr/bin/bash searx
sudo install -o searx -g searx -m 0755 -d /opt/searx

Nun loggt ihr euch für die Installation von Searx als searx auf dem System ein:

sudo su - searx

Schritt 3: Searx-Repository herunterladen

Nun klont ihr das Git-Repository mit dem Searx-Quellcode ins Verzeichnis ~/src:

git clone https://github.com/searx/searx.git src

Schritt 4: Python-Umgebung einrichten

Jetzt erstellt ihr über Python im Home-Verzeichnis von searx das Virtual Environment im Verzeichnis ~/env und richtet die Shell so ein, dass ihr bei der nächsten Anmeldung mit su - searx im Virtual Environment landet. In dieses Virtual Environment werden dann im nächsten Schritt die für die Searx-Instanz benötigten Python-Module installiert.

python3 -m venv env
echo ". ~/env/bin/activate" > .profile

Wenn ihr euch nun von dem searx-Konto ab- und wieder anmeldet, dann solltet ihr euch erfolgreich in der virtuellen Python-Umgebung befinden, die sich an dem veränderten Shell-Prompt erkennen lässt:

(env) searx@hostname:~$

Um die Umgebung wieder zu verlassen, müsst ihr lediglich deactivate im Terminal ausführen, welches eine vom activate-Skript definierte Shell-Funktion ist, die eure „normale“ Shell-Umgebung wiederherstellt.

Falls ihr nicht automatisch nach dem Anmelden in die virtuelle Umgebung wechseln wollt, könnt ihr den Schritt mit der .profile auch weglassen und immer manuell . ~/env/bin/activate aufrufen.

Schritt 5: Erforderliche Python-Module installieren

Aus dem zuvor erstellten Virtual Environment ruft ihr nun pip auf, um die für die Searx-Umgebung erforderlichen Module zu installieren (bzw. bereits vorhandene Module wie pip zu aktualisieren). Kombiniert geht das so:

pip install -U pip setuptools wheel pyyaml

Jetzt müssen noch die projektspezifischen Python-Module von Searx aus der src/requirements.txt installiert werden. Wechselt dazu ins ~/src-Verzeichnis mit dem Searx-Quellcode und führt folgendes pip-Kommando aus:

pip install -e .

Hinweis: Wenn ihr den Quellcode eurer Searx-Instanz regelmäßig mit git pull aktualisiert und es Änderungen an den projektspezifischen Modulen (requirements.txt) gegeben hat, dann müsst ihr das vorherige pip-Kommando erneut ausführen, damit die zuvor installierten Python-Module in eurem Virtual Environment aktualisiert werden!

Schritt 6: Searx-Konfiguration erstellen

Searx ist nun fast startbereit! Jetzt muss lediglich noch eine Konfigurationsdatei erstellt werden. Dazu wechselt ihr wieder in das Home-Verzeichnis und kopiert euch die Template-Konfigurationsdatei nach ~/settings.yml:

cp src/utils/templates/etc/searx/use_default_settings.yml settings.yml

Aus „kryptographischen Gründen“ müsst ihr vor dem Starten der Searx-Instanz den in der Template-Konfigurationsdatei enthaltenen Platzhalter-Secret-Key durch einen eigenen ersetzen. Dazu führt ihr folgendes Kommando aus (oder ihr bearbeitet die Datei von Hand und fügt etwas Zufälliges an entsprechender Stelle ein):

sed -i "s/ultrasecretkey/$(openssl rand -hex 16)/" settings.yml

Im letzten Schritt vor dem Starten von Searx müssen wir Searx über die Umgebungsvariable SEARX_SETTINGS_PATH noch mitteilen, wo denn die soeben erstellte Konfigurationsdatei zu finden ist. Aus Gründen der Einfachheit würde ich empfehlen, die Umgebungsvariable einfach direkt in der ~/.profile zu exportieren:

echo "export SEARX_SETTINGS_PATH=~/settings.yml" >> .profile

Nach einer erneuten Anmeldung im searx-Konto ist die Umgebungsvariable automatisch gesetzt und muss somit nicht jedes Mal manuell exportiert werden, wenn ihr Searx über die Shell aus dem virtualenv starten wollt.

Schritt 7: Searx-Instanz starten und ausprobieren

Nachdem alles erfolgreich durchführt wurde, kann Searx nun aus der Python-Umgebung gestartet werden.

python src/searx/webapp.py

Im Terminal solltet ihr jetzt sehen, dass Searx gestartet wurde und der Webserver auf 127.0.0.1:8888 lauscht. Als Development-Server kommt Werkzeug zum Einsatz, der hier nur dazu dient, die Installation zu testen.

 * Serving Flask app 'webapp' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
INFO:werkzeug: * Running on http://127.0.0.1:8888/ (Press CTRL+C to quit)

Falls ihr Searx auf einem Remote-Server installiert habt und von eurem Desktop aus schnell die Installation testen wollt, ohne server.bind_address auf 0.0.0.0 setzen zu müssen und/oder in der Server-Firewall den Port zu öffnen, dann könnt ihr wie folgt ganz einfach eine Port-Weiterleitung über SSH von eurem Desktop zum Server aufmachen:

ssh -L 8888:127.0.0.1:8888 -N [...]

… und dann http://localhost:8888 im Webbrowser auf dem Desktop aufrufen.

Im nächsten Beitrag zum Thema geht es dann um die Installation und Konfiguration des uWSGI-Servers für den „Produktiveinsatz“ und wie man diesen über Apache und nginx als Reverse-Proxy anspricht.

Die Strategic Response Unit (SRU)

Es geht um ein Team der Strategic Response Unit (SRU), eine Spezialeinheit der kanadischen Polizei von Toronto, die gerufen wird, wenn normale Polizisten in brenzligen Situationen nicht mehr weiter wissen. Das können Bombendrohungen, Geiselnahmen, Banküberfälle und ähnliche Dinge sein. Im Gegensatz zu anderen Polizeiserien auf diesem Gebiet geht es bei Flashpoint aber nicht immer nur darum, die Zielperson mit möglichst viel Action abzuknallen. Action kommt bei Flashpoint zwar auf jeden Fall reichlich vor, allerdings können viele Situationen auch durch Reden, Zuhören und Verhandlungsgeschick gelöst werden, ohne dass jemand durch einen tödlichen Sierra-Schuss sterben muss, der von einem der Scharfschützen im Team abgegeben wird, wenn der Skorpion-Befehl kommt.

Enrico Colantoni (auch bekannt aus seiner späteren Rolle in der Serie Person of Interest) spielt den Teamchef Sgt. Greg Parker. 😎

Flashpoint hebt besonders die menschliche Seite von sowohl den Teammitgliedern als auch den Zielpersonen hervor. Als Zuschauer kann man oft nachvollziehen, warum die Zielperson überhaupt in eine solch missliche Lage wie zum Beispiel eine Geiselnahme geraten ist, was diesen Menschen dazu getrieben hat. Denn nicht immer ist die Zielperson eine böse Person (es gibt auch wirklich böse Arschlöcher, aber meistens ist es dann doch nicht so einfach).

Man bekommt hier keine bestimmte Sichtweise eingetrichtert, sondern kann sich selbst ein Bild von beiden Seiten machen. Der Schusswaffengebrauch ist für die Teammitglieder lediglich die letzte Option, wenn alles andere ausgeschöpft ist. Und wenn dies passiert, dann geht dies auch nicht einfach so an den Charakteren vorbei als wenn sie gefühlslose Killermaschinen wären. Das macht diese Serie für mich jedenfalls so besonders und authentisch.

Die echte Emergency Task Force (ETF)

Das fiktive Team von Flashpoint basiert auf einem Team der real existierenden Emergency Task Force (ETF) von Toronto, bei denen die Flashpoint-Darsteller auch ein Training absolviert haben, um deren Vorgehensweisen besser zu verstehen. So konnten sie lernen, wie das echte Team der ETF von Toronto sich in bestimmten Situationen verhält; wie sie verhandeln, die Situation unter Kontrolle bringen oder ein gefährliches Objekt wie ein Haus einnehmen und sichern.

Am Set ist außerdem immer der im Ruhestand befindliche Barney McNeily mit dabei, der 17 Jahre in der echten ETF war. Er achtet darauf, dass es weitestgehend realistisch und authentisch zugeht.

Anmerkung: Diese Informationen habe ich aus einem fast einstündigen Interview (Extras von Staffel 1) mit den Darstellern aus dem Team und weiteren beteiligten Personen (darunter auch die Autoren von Flashpoint: Mark Ellis und Stephanie Morgenstern). Außerdem kann ich noch das Video The creation of Flashpoint empfehlen, in dem noch weitere Informationen enthalten sind. 😉

sudo mysql -u root

Das hat den Vorteill, dass Dienste und Skripte, die als root laufen, kein Passwort mehr benötigen um sich als MySQL-Root anzumelden (zum Beispiel Backup-Skripte, in die man ansonsten immer das MySQL-Root-Passwort eingetragen hätte).

"dann setze ich halt ein MySQL-Root-Passwort"

Aus Gewohnheit möchte man jetzt ein Passwort für den root-Benutzer vergeben, damit man sich auch über eine Schnittstelle wie phpMyAdmin einloggen und den Server administrieren kann (sofern man nicht auf der Kommandozeile arbeitet). Das kann ich aber nicht empfehlen, da andere Dienste davon ausgehen, dass sie sich direkt über das Socket mit root-Rechten (Linux Root) ohne Passwort authentifizieren können. Wenn man nun einfach ein Passwort für den Benutzer definiert, dann funktionieren diese Dienste eventuell nicht mehr und man erhält am nächsten Morgen eine Mail vom Cron Daemon mit einer Fehlermeldung wie zum Beispiel:

/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '[…]'
run-parts: /etc/cron.daily/logrotate exited with return code 1

Dort kann man erkennen, dass versucht wurde, sich ohne Passwort zu authentifizieren, was dann aber aufgrund eines gesetzten Passworts fehlgeschlagen ist. Also, anstatt den Datenbankbenutzer root anzufassen, empfehle ich, einfach einen neuen Benutzer zur Administration anzulegen, mit dem man sich auch über phpMyAdmin einloggen kann.

Einen neuen Administrations-Benutzer anlegen

sudo mysql -u root

CREATE USER 'admin'@'localhost' IDENTIFIED BY 'password_here';
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;

Es gibt übrigens auch noch ein Skript namens mysql_secure_installation, aber das definiert auch wieder ein Passwort für den root-Benutzer, was doof ist.

Nachtrag vom 09.10.2017: Der Artikel wurde verkauft und ist nicht mehr verfügbar.

Eingebettetes Video
https://www.youtube.com/watch?v=xMtbGy3BThc

Hier war ein YT-Video über eine Invidious-Instanz eingebunden. Wegen technischen Maßnahmen von Google, mit denen das Invidious-Projekt gerade zu kämpfen hat, können hier momentan keine YT-Videos via Invidious eingebunden werden.

Ein metallischer Geschmack kann laut meinen Recherchen nur durch Freistrecken bzw. Hotspots entstehen, aber auch durch Verunreinigungen an den Polen, in die man die Drähte schraubt.

Ich habe mehrere neue Wicklungen gemacht, aber der Geschmack ging einfach nicht weg. Letztendlich habe ich den Lush komplett auseinander genommen und in heißes Wasser eingelegt. Danach habe ich mir die Löcher mal ganz genau angeguckt und auch das Problem gefunden.

In zwei von vier Löchern befanden sich winzige Drahtstückchen (maximal einen Millimeter lang), die sehr schwer zu erkennen waren. Ich war mir ziemlich sicher, dass dies das Problem sein muss und habe dann wieder eine neue Microcoil eingebaut. Und schon schmeckt man nur noch den typischen "Neue-Watte-Geschmack" und nicht mehr diesen ekligen metallischen Geschmack.

Ich hätte mir die Pole mal viel früher schon anschauen sollen. Im Nachhinein wird mir auch klar, warum manche Schrauben nicht ganz so weit rein gingen wie andere. Merken! 😲

So konnte ich die drei Romane aus der Metro-Reihe von Dmitry Glukhovsky nachkaufen (ich überprüfe zwischendurch immer mal manche Titel, ob es diese endlich ohne DRM gibt).

Das ist doch eine positive Entwicklung! 😊

Dort kann man sich registrieren und bekommt dann (sofern man ausgelost wurde) ein Jahr lang jeden Monat 1.000 EUR bedingungsloses Grundeinkommen, das über Crowdfunding finanziert wird.

Jeder kann einfach mitmachen, und sobald 12.000 EUR via Crowdfunding eingenommen wurden, wird das nächste Grundeinkommen ausgelost. Ich habe mich heute auch dort registriert und mit zwei anderen Bekanntschaften an der Verlosung teilgenommen, aber wir hatten kein Glück (bei der Vielzahl an Teilnehmern, die sich dort registrieren aber vorhersehbar). 😉