Cookie-Hinweise Blockieren

Wer im Netz unterwegs ist, stößt derzeit ständig auf Cookie-Hinweise, die den Nutzer daran erinnern, dass sein Surfverhalten aufgezeichnet wird. Vor Jahren von der EU als nützliche Datenschutzinformation eingeführt, ist die jetzige Flut dieser Hinweise für viele Nutzer nur noch ein lästiges Hindernis.

Dieser Hinweis ist meiner Meinung nach relativ sinnlos, weil fast jede Website Cookies verwendet. Eine aktuelle Studie spricht etwa von 95 Prozent aller Websites, die das Surfverhalten der Nutzer mit Cookies und anderen ausgefeilten Methoden systematisch aufzeichnen.

Google löste Hinweiswelle aus

Eigentlich hat die EU bereits 2009 in der Cookie-Richtlinie festgelegt, dass eine Website das Onlineverhalten seiner Besucher nur dann speichern darf, wenn der einzelne User dem vorher zugestimmt hat. Die EU-Vorgaben wurden allerdings nie umgesetzt. Als gängige Praxis wurde bisher die Aufklärung mittels Datenschutzerklärung im Impressum als ausreichend angesehen.

Hinter der jetzigen Flut an Cookie-Hinweisen steckt ausgerechnet Google, der mit Abstand größte Datensammler im Internet. Im Herbst letzten Jahres verpflichtete Google all seine Werbepartner, die EU-Richtlinie zu befolgen und auf Cookies hinzuweisen. Das Ergebnis bekommen die Nutzer seit Monaten massenweise zu sehen.

Cookie weiß was Nutzer tun

Bei jedem Websitebesuch hinterlässt der Nutzer Spuren. Diese werden von den Betreibern der Websites gespeichert und ausgewertet. Das nennt man Tracking. Dabei kommen unter anderem Cookies zum Einsatz, kleine Textdateien, welche die personenbezogenen Informationen direkt auf dem Computer des Nutzers speichern. Ursprünglich wurden die Cookies eingeführt, um sich zu merken, was der Benutzer vorher auf der Seite gemacht hat. Auch Facebook nutzt die Technik rigoros um anhand des Surfverhalten der Nutzer die passenden Produkte platzieren zu können.

Cookies zeichnen klares Bild des Nutzers

Mit Hilfe der Cookies können die Websitebetreiber genau nachvollziehen, welche Videos wann angeschaut und welche Produkte wie oft aufgerufen wurden. Aus einer Fülle von Einzeldaten zeichnen sie so eine ausführliche Datenspur, die ein klares Bild des Nutzers ergeben.

Sollte man manche Cookies also besser nicht erlauben? Das gezielte Ausschalten einzelner Cookies ist technisch möglich, aber unrealistisch für den Endnutzer. Das Blockieren aller Cookies ist hingegen technisch einfach möglich, hat aber den Nachteil, dass dann viele Funktionen von Webseiten einfach nicht mehr funktionieren. Zum Beispiel das automatische Log-in und das Hinterlegen von Produkten im Warenkorb.

Im Browser Cache gespeicherten Cookies löschen

Die im Browser Cache gespeicherten Cookies können mit Plugins wieder gelöscht werden, wie mit dem Click&Clean, dieses beim beenden des Browsers alle Cookies und bei bedarf den Verlauf und weitere Daten aus dem Cache entfernt.

Cookie-Warnungsblocker bringen Ruhe

Ein Browser Plugin mit dem bezeichnenden Namen „I don’t care about Cookies“ existiert bereits. Einmal im Browser installiert, werden die Hinweise einfach ausgeblendet. Auch Adblock und uBlock (Fanboy’s Cookiemonster List) bieten Filter gegen die massenhaften Hinweise an. Andere Filter wie zum Beispiel „Ghostery“ und „Disconnect“ zeigen an, wie viele Cookies auf welcher Website im Einsatz sind, denn bei vielen Websites weiß man nicht was alles im Hintergrund noch sonst so läuft.

uBlock Origin: Dashboard – Vorgegebene Filter

 

Ubuntu Network Manager systemd-resolved

Ubuntu nutzt das resolvconf-Programm zur Konfiguration der lokalen DNS Auflösung. Das resolvconf-Paket umfasst eine einfache Datenbank und eine Laufzeit zur dynamischen Änderung von Nameserver-Informationen.

Ubuntu Network Manager resolvconf

Normalerweise wird das Programm resolvconf über eine Netzwerkschnittstelle ausgeführt, um Routinen wie ifup, ifdown, NetworkManager, dhclient und pppd, oder lokale Nameserver wie dnsmasq zu pushen um die Nameserver-Informationen zu updaten.

Kommen auf einem Host statische IP Adressen und DNS Einträge zur Anwendung, sollte unter Ubuntu das resolvconf-Paket deaktiviert werden, damit nicht automatisch die DNS Konfiguration aus dem dnsmasq daemon vorgenommen wird, die Konfiguration die man in /etc/resolv.conf und /etc/network/interfaces editiert hat, werden sonst durch das resolvconf-Programm wieder überschrieben.

Ubuntu resolvconf deaktivieren

$ resolvconf --disable-updates

resolvconf im Autostart deaktivieren und das Programm beenden.

$ systemctl disable systemd-resolved.service
$ service systemd-resolved stop

Den Network Manager auf default DNS ändern.

$ vi /etc/NetworkManager/NetworkManager.conf
..
dns=default
..

Den Symlink resolv.conf unter /etc entfernen.

$ rm /etc/resolv.conf

und eine neue resolv.conf Datei mit Nameserver erstellen. In diesem Beispiel sind es die Google Public DNS.

  In einem lokalen Netzwerk, oder einer ADS sollten die internen Nameserver genutzt werden.

$ vi /etc/resolv.conf

nameserver 8.8.8.8
nameserver 8.8.4.4

Die resolv.conf Datei des systemd Konfigurationsprogramm löschen.

$ rm /etc/systemd/resolved.conf

Änderung der Konfiguration ausführen.

$ service network-manager restart

Die Nameserver können auch in der Interface Konfiguration eingetragen werden.

$ vi /etc/network/interfaces

auto lo
iface lo inet loopback

auto ens160
iface ens160 inet static
  address 10.10.0.8
  gateway 10.10.0.1
  netmask 255.255.255.0
  network 10.10.0.0
  broadcast 10.10.0.255
  dns-nameservers 8.8.8.8 8.8.4.4
  dns-search my.local

  Die Interface Bezeichnung (ens160) kann abweichen und muss der des jeweiligen Host entsprechen.

  Die Datei /etc/resolv.conf sollte keineswegs fehlen.

Um die geänderte Netzwerk Konfiguration zu aktivieren muss diese in den Stack eingelesen werden.

$ /etc/init.d/networking restart

Troubleshooting DNS

Viele Netzwerk Probleme beruhen auf fehlerhaften DNS oder falscher Konfiguration der resolver. In einem Heimnetzwerk gibt es oft keine internen DNS, dabei kann der Router oder die Firewall als Nameserver genutzt werden, wie beispielsweise die FRITZ!Box. Grundsätzlich sollte sichergestellt werden, das die eingesetzte Firewall über ein DNS Cache verfügt, bei semiprofessionellen Firewalls wie die FortiGate verfügt nicht jedes Modell über einen solchen Cache. Bei Open Source basierten Firewalls hingegen bieten die meisten über DNS forwarder oder dnsmasq für den DNS Cache.

Nach Änderungen der Nameserver bei Windows sollte der DNS Cache zurückgesetzt werden, dazu eine Eingabeaufforderung öffnen mit Win+Rcmd

C:\> ipconfig /flushdns

Bei Linux kann der DNS Cache in einem Terminal zurückgesetzt werden, mit eines der folgenden Kommandos, je nachdem welcher Dienst installiert ist.

$ sudo /etc/init.d/nscd restart
$ service nscd restart
$ service nscd reload
$ sudo /etc/init.d/dnsmasq restart
$ service dnsmasq restart
$ rndc reload

Im Mac OS X   Terminal als root.

$ lookupd -flushcache

Ist kein interner DNS vorhanden, können die Nameserver des jeweiligen Internet Provider eingesetzt werden, oder die Cloudflare public DNS.

1.1.1.1 1.0.0.1

Beispiel einer Nameserver abfrage seines Providers unter Windows.

C:\> nslookup -type=ns green.ch
Server:  dns1.agrinet.ch
Address:  81.221.250.11

Nicht autorisierende Antwort:
green.ch        nameserver = dns2.agrinet.ch
green.ch        nameserver = dns1.agrinet.ch

dns1.agrinet.ch internet address = 81.221.250.11

Beispiel Nameserver lookup query bei Linux.

$ host -t ns green.ch
green.ch name server dns1.agrinet.ch.
green.ch name server dns2.agrinet.ch.

$ host dns1.agrinet.ch & host dns2.agrinet.ch
dns1.agrinet.ch has address 81.221.250.11
dns2.agrinet.ch has address 81.221.252.11
dns2.agrinet.ch has IPv6 address 2a01:2a8:2001:252::11

Ein Ping -n1 löst Adressen zu Hostnamen auf mit Parameter -a und -4 für IPv4 Adresse.

C:\> ping -4 -n 1 -a www.google.com

Ping wird ausgeführt für www.google.com [216.58.201.4] mit 32 Bytes Daten:
Antwort von 216.58.201.4: Bytes=32 Zeit=32ms TTL=50

Ping-Statistik für 216.58.201.4:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 32ms, Maximum = 32ms, Mittelwert = 32ms

Abfrage der aktuellen DNS-Nameserver die systemd resolver nutzt.

$ systemd-resolve --status