//
Kolumne
14 Min. Lesezeit

Alexa & Co. – die stille Abhängigkeit im Wohnzimmer

Kolumne

„Alexa, schalte das Licht an.” Ein kurzer Satz, ein kurzes Klick, die Lampe geht an. So einfach sich das anfühlt, so unsichtbar bleibt, was in der Sekunde davor und danach passiert. Ein Mikrofon horcht, ein Server irgendwo in Dublin oder Virginia wertet aus, ein Profil wird gepflegt, eine Werbezielgruppe wird bestätigt. Und der Nutzer? Der freut sich über das Licht.

Smarte Lautsprecher wie Alexa, Google Assistant und Siri sind die einprägsamsten Gesichter einer Entwicklung, die längst nicht mehr beim Lautsprecher auf dem Küchenschrank endet. Sie stehen Modell für eine viel breitere Frage: Wie viel Infrastruktur, wie viel Datentransfer und wie viel fremde Kontrolle akzeptieren wir für ein bisschen Komfort?

Dieser Artikel baut auf dem Gedanken auf, den ich im Beitrag Was wäre – Wenn die Tech-Giganten Europa den Stecker ziehen skizziert habe. Dort ging es um das Szenario eines großflächigen Ausfalls US-amerikanischer Dienste. Hier geht es um die Alltagsseite derselben Medaille: nicht der plötzliche Stecker, sondern das ständige Tropfen, das die Höhle aushöhlt.

Der Lautsprecher, der nie schweigt

Ein Echo-Gerät im Standby ist kein stummes Gerät. Wer einmal ein Pi-hole im eigenen Netz betrieben und das Query-Log eine Stunde lang beobachtet hat, weiß das. api.amazonalexa.com, device-metrics-us.amazon.com, fls-na.amazon.com, unagi-na.amazon.com, spectrum.s3.amazonaws.com – die Liste der Domains, die ein scheinbar untätiger Echo-Lautsprecher kontaktiert, ist lang und wächst mit jedem Firmware-Update.

Im Beitrag Pi-hole und Quad9 am Raspberry Pi habe ich das schon angesprochen: Bei mir ist api.amazonalexa.com nach einer Stunde die mit Abstand meistangefragte Domain. Das Gerät pollt ununterbrochen Alexa-Server, sendet Nutzungsmetriken, meldet Zustände, hält Verbindungen offen. Wer das zum ersten Mal im Log sieht, ändert oft schlagartig sein Verhältnis zum Begriff „Standby”.

Google und Apple machen es grundsätzlich nicht anders. Nest-Hubs, Chromecast-Geräte, HomePods und Apple TVs funken equally ununterbrochen in die jeweiligen Heimat-Rechenzentren. Die Domains heißen nur anders. Das Prinzip bleibt: Ein Smart-Home-Gerät ohne permanente Cloud-Anbindung ist für diese Ökosysteme schlicht nicht vorgesehen.

Der Smart TV, der sich selbst weckt

Ein besonders eindrückliches Beispiel aus meinem eigenen Netzwerk ist ein Samsung-Fernseher. Smart TVs gelten als bekannte Datenkrake, das ist nicht neu. Was aber erst sichtbar wird, wenn man nicht nur Pi-hole betreibt, sondern zusätzlich Home Assistant als zentrale Smart-Home-Plattform laufen hat, ist das Ausmaß der Eigenaktivität des Geräts.

Im Pi-hole-Log führt der Samsung im laufenden Betrieb die Statistik mit Abstand an – noch vor dem Echo-Gerät. Hunderte Anfragen pro Stunde, verteilt auf Dutzende Domains: Telemetrie-Endpunkte, Werbe-Pings, ACR-Automatic-Content-Recognition-Server, App-Store-Metriken, Firmware-Checks, Empfehlungs-Tracking. Und das, während der Fernseher scheinbar nur läuft, weil gerade eine Sendung läuft.

Das eigentlich Irritierende habe ich aber erst in Home Assistant gesehen: Der Fernseher geht im Standby wiederholt von selbst an – manchmal für ein paar Sekunden, manchmal für mehrere Minuten –, ohne dass jemand die Fernbedienung berührt. In der Historie des Geräts in Home Assistant tauchen diese Eigen-Einschaltungen regelmässig auf, oft nachts, oft zu regelmässigen Zeiten. Vermutlich, um Updates zu ziehen, EPG-Daten zu pflegen, Werbe- und Empfehlungsprofile abzugleichen oder einfach, um dem Hersteller mitzuteilen, dass das Gerät noch existiert und erreichbar ist. Offiziell ist das alles „Standby”. Praktisch bedeutet es: Ein Gerät in der Wohnung, das sich selbst aktiviert, Netzwerkverbindungen aufbaut und Daten sendet, ohne dass der Nutzer etwas davon merkt – außer, der Bildschirm flackert kurz auf oder die Stromanzeige ändert sich.

Wer so etwas einmal in der Historie gesehen hat, versteht, warum „Standby” bei moderner Unterhaltungselektronik ein unzuverlässiger Begriff ist. Der Fernseher ist nicht aus. Er wartet nicht. Er arbeitet – für den Hersteller, nicht für den Eigentümer. Als ich das zum ersten Mal in der Historie sah, war ich ehrlich erschrocken – nicht wegen des einzelnen Geräts, sondern weil mir klar wurde, dass ich vorher nie gefragt hatte, was in meinem eigenen Wohnzimmer eigentlich passiert, wenn ich es nicht ansehe.

Was eigentlich gesammelt wird

Die offizielle Lesart der Hersteller ist beruhigend: Das Gerät höre nur auf das Wake-Word, verarbeite Sprache lokal, sende nur nach Aktivierung, und am Ende könne man die Aufnahmen sogar löschen. Das ist nicht falsch – aber es ist unvollständig.

Tatsächlich fallen mehrere Datenströme an:

  • Wake-Word-Erkennung – findet zwar lokal statt, aber das Gerät muss dafür kontinuierlich das Audiosignal puffern und auswerten. Wer garantiert, dass nur das Wake-Word die Schwelle passiert?
  • Sprachaufnahmen nach Aktivierung – werden zur Transkription an Server geschickt, dort verarbeitet und – je nach Einstellung – gespeichert. Manuell löschbar, aber eben erst einmal vorhanden.
  • Geräte- und Nutzungstelemetrie – Verbindungszeiten, Neustarts, Fehlercodes, genutzte Skills, Lautstärkeprofile, Standby-Zeiten. Läuft ununterbrochen und unabhängig davon, ob gerade gesprochen wird.
  • Smart-Home-Zustände – welche Lampe an ist, wann der Rollladen fährt, welche Temperatur der Thermostat meldet. All das läuft über die Cloud des Herstellers, nicht nur lokal.
  • Kontextdaten – Account-ID, Geräte-ID, IP-Adresse, WLAN-Informationen, Standort über IP-Geolokation.

Aus diesen Einzelteilen entsteht ein Bild, das weit über „Licht an, Licht aus” hinausgeht. Wann jemand zu Hause ist, wann er aufsteht, wann er schlafen geht, wie viele Geräte er besitzt, welche Marken er bevorzugt, welche Skills er nutzt, welche Musik er hört – alles ableitbar, alles protokollierbar, alles im besten Fall anonymisiert, im realistischen Fall verknüpfbar.

Wie Marketing diese Daten nutzt

Hier wird es interessant. Die Daten landen nicht in einem luftleeren Raum, sondern in Maschinen, deren Aufgabe es ist, sie wirtschaftlich nutzbar zu machen.

Amazon betreibt eines der größten Werbe- und Empfehlungssysteme der Welt. Dessen Treibstoff sind Signale: Klicks, Käufe, Suchanfragen – und eben auch Smart-Home-Nutzung. Wer einen Echo in der Küche hat und regelmäßig Koch-Skills nutzt, liefert Signale, die in Empfehlungen für Töpfe, Gewürze, Kochbücher und Lebensmittel-Lieferdienste einfließen können. Wer morgens um 6:30 den Wecker per Sprache stellt und abends um 22:15 das Licht dimmt, liefert ein Profil, das für Werbung mit hoher zeitlicher Trefferwahrscheinlichkeit verwertbar ist.

Google verknüpft Assistant-Daten mit dem Google-Account und damit mit Search, YouTube, Maps, Android. Apple positioniert sich datenschutzfreundlicher, nutzt Gemini-Daten aber ebenfalls zur Verbesserung von Modellen und – in aggregierter Form – für das eigene Werbegeschäft, das seit einigen Jahren massiv ausgebaut wird.

Wichtig ist: Es geht nicht darum, dass jemand mithört und mitschreibt. Es geht um automatisierte Profilverarbeitung in industriellem Maßstab. Der einzelne Nutzer ist für den Konzern nicht interessant als Person, sondern als Datenpunkt in einem Profil, das mit Millionen anderen Datenpunkten verknüpft wird. Genau diese Skalierung macht die Verarbeitung so wirksam – und so schwer zu begreifen.

Im Artikel Zwischen Komfort und Privatsphäre habe ich das schon so formuliert: Wenn jeder Datenverarbeitungsvorgang einen Piekser auslöste, würden wir anders über Datenschutz denken. Bei Alexa & Co. piekst nichts. Die Verarbeitung ist unsichtbar, kontinuierlich und in ihrer Menge kaum vorstellbar.

Die Abhängigkeit, die man nicht sieht

Die eigentliche Abhängigkeit beginnt nicht beim Mikrofon, sondern bei der Infrastruktur dahinter. Ein Echo ohne Amazon-Cloud ist ein teurer Papierbeschwerer. Ein Nest-Hub ohne Google-Dienste ist ein Bilderrahmen ohne Bilder. Ein HomePod ohne Apple-Account ist ein Bluetooth-Lautsprecher mit schlechtem Klang.

Das ist die gleiche Logik, die ich im Was-wäre-wenn-Artikel für Cloud-Dienste, SaaS und Ökosysteme beschrieben habe – nur dass sie im Smart Home besonders unmittelbar spürbar wird. Wenn Amazon die Alexa-Server abschaltet, geht nicht nur die Sprachsteuerung. Es geht das Licht, wenn es über Alexa-Routinen geschaltet wird. Es geht die Heizung, wenn der Thermostat über Alexa gesteuert wird. Es gehen Szenen, Automatisierungen, Wecker, Einkaufslisten. Nicht, weil die Hardware defekt wäre, sondern weil die Logik zentral in einer Cloud liegt, auf die der Nutzer keinen Zugriff hat.

Wer ein Smart Home aufbaut, das primär über Alexa- oder Google-Routinen läuft, baut faktisch eine Außenstelle von Amazons oder Googles Infrastruktur in seiner eigenen Wohnung. Die Hardware gehört ihm. Die Steuerung gehört dem Konzern.

Was Pi-hole in diesem Setup leistet – und was nicht

Pi-hole ist in diesem Kontext ein Diagnose- und Filterwerkzeug, keine Lösung für das Grundproblem. Wer sich für die praktische Einrichtung interessiert, findet die Details im Artikel Pi-hole und Quad9 am Raspberry Pi. Hier geht es um die Einordnung.

Was Pi-hole leistet:

  • Sichtbarkeit. Wer ein Echo-Gerät ins Netz hängt und Pi-hole laufen hat, sieht innerhalb von Minuten, wie viele Anfragen pro Minute abgehen, an welche Domains, in welchem Rhythmus. Das Query-Log ist die beste Aufklärung, die man bekommen kann, ohne den Verkehr selbst mitzuentschlüsseln.
  • Blockieren von Telemetrie- und Werbe-Domains. Ein Teil der Anfragen – etwa Werbe-Pings, certain Metrik-Endpunkte, Empfehlungs-Tracking – lässt sich über Blocklisten wie HaGeZi, OISD oder StevenBlack’s Unified Hosts blockieren. Das reduziert die ausgehende Datenmenge spürbar.
  • Netzwerkweite Wirkung. Anders als Browser-Erweiterungen greift Pi-hole für jedes Gerät im Netz, auch für solche, auf denen sich nichts installieren lässt – und genau dazu gehören Echo, Nest und HomePod.
  • Bewusste Entscheidung. Wer im Pi-hole sieht, dass ein Echo-Gerät pro Stunde hunderte Anfragen absetzt, überlegt mit anderem Wissen, ob er es weiterbetreiben will.

Was Pi-hole nicht leistet:

  • Funktionsnotwendige Cloud-Anfragen blockieren. Ein Echo ohne Anbindung an api.amazonalexa.com ist kein Echo mehr. Wer diese Domain blockiert, blockiert das Gerät. Pi-hole kann also nicht die Abhängigkeit auflösen, sondern nur die Begleiterscheinungen reduzieren.
  • First-Party-Tracking erkennen. Was über dieselbe Domain läuft wie die Kernfunktion – also über amazon.com selbst –, lässt sich auf DNS-Ebene nicht trennen. Pi-hole sieht nur Ziele, nicht Inhalte.
  • Verschlüsselten Inhalt filtern. Was innerhalb einer HTTPS-Verbindung übertragen wird, bleibt für Pi-hole unsichtbar. Es blockiert auf Namensebene, nicht auf Inhaltsebene.
  • Die Grundlogik des Geräts ändern. Ein Echo ist darauf gebaut, Cloud-abhängig zu sein. Kein DNS-Filter macht daraus ein lokales Gerät.

Pi-hole ist also in diesem Kontext vor allem eines: ein Werkzeug der Aufklärung. Es beendet nicht die Abhängigkeit, aber es macht sie sichtbar. Und Sichtbarkeit ist die Voraussetzung für jede bewusste Entscheidung.

Alternativen, die wirklich unabhängig machen

Wer nicht nur filtern, sondern die Abhängigkeit auflösen will, kommt an einem Wechsel der Plattform nicht vorbei. Die gute Nachricht: Im Smart-Home-Bereich gibt es inzwischen ernsthafte Alternativen, die lokal laufen und ohne Cloud auskommen.

  • Home Assistant – die ausgereifteste Open-Source-Plattform für Smart Home. Läuft lokal auf einem Raspberry Pi, einem Mini-PC oder einem NUC. Sprachsteuerung ist über lokale Wake-Word-Erkennung (z. B. Wyoming Protocol, Whisper) möglich, ohne dass ein Audiosignal das Haus verlässt. Integrationen existieren für praktisch jedes Protokoll – Zigbee, Z-Wave, Matter, MQTT, KNX. Ich habe dazu bereits eigene Versuche unternommen, unter anderem mit dem M5Stack Atom Echo und der Home Assistant Voice Preview Edition. Die Einrichtung ist komplex, die Alternative aber spannend – mehr dazu im nächsten Artikel.
  • openHAB – ähnliches Konzept wie Home Assistant, eher auf Java-Basis und mit etwas anderer Philosophie. Ebenfalls lokal, ebenfalls offen.
  • Homebridge / ioBroker – weitere Optionen, je nach Vorerfahrung und Anforderungen.
  • Matter und Thread – Standards, die lokal funktionieren und Herstellerunabhängigkeit versprechen. Voraussetzung: Geräte, die Matter sauber implementieren. Bei der Auswahl neuer Geräte lohnt es sich, auf Matter-Unterstützung zu achten.
  • Lokale Sprachassistenten – Projekte wie Home Assistant Voice PE oder Rhasspy zeigen, dass Sprachsteuerung ohne Cloud möglich ist. Komfortabel anders als Alexa, aber funktional und – vor allem – privat.

Wer diesen Weg geht, gibt Komfort ab. Die Einrichtung ist aufwendiger, die Spracherkennung ist weniger robust, die Integrationen müssen gepflegt werden. Aber am Ende steht ein Smart Home, das funktioniert, auch wenn Amazon, Google oder Apple ihre Server abschalten. Und das ist genau der Punkt, der den Bogen zurück zum Was-wäre-wenn-Szenario schlägt: Wer sein Smart Home lokal betreibt, gehört zu den Selbsthostern, für die ein solcher Ausfall ein Lärm ist, kein Kollaps.

Die eigentliche Frage

Alexa & Co. sind nicht das Problem. Sie sind nur die sichtbarste Ausprägung eines Musters, das durch unsere gesamte digitale Infrastruktur läuft: Komfort gegen Kontrolle, Bequemlichkeit gegen Souveränität, kostenlos gegen Daten.

Wer das bewertet, sollte zwei Dinge nicht verwechseln:

  1. Es geht nicht um Böswilligkeit. Die Hersteller bauen Systeme, die funktionieren, die Nutzer wollen, die sich verkaufen. Niemand in Seattle sitzt nachts am Mikrofon und hört zu. Aber die Struktur, die daraus entsteht, ist trotzdem problematisch – weil sie Abhängigkeit erzeugt, weil sie Datenströme zentralisiert, die nie hätten zentralisiert werden müssen, und weil sie Kontrolle an Akteure abgibt, die nicht dem Nutzer gegenüber verantwortlich sind, sondern ihren Aktionären.
  2. Es geht nicht um Verzicht. Smart Home ist nicht per se schlecht. Sprachsteuerung ist nicht per se schlecht. Cloud-Anbindung ist nicht per se schlecht. Es geht um die Frage, ob man die Infrastruktur versteht, kontrolliert und – wenn nötig – ohne fremde Erlaubnis weiterbetreiben kann. Genau das ist die Definition digitaler Souveränität, die im Digitalen Manifest formuliert ist.

Pi-hole macht den Anfang. Es zeigt, was im Hintergrund passiert. Home Assistant zeigt, wie es anders geht. Das Bewusstsein, dass ein Echo im Wohnzimmer kein lokal begrenztes Gerät ist, sondern ein Cloud-Endpoint mit Mikrofon, ist der Schritt dazwischen.

Die Frage ist nicht, ob man Alexa nutzen darf. Die Frage ist, ob man weiß, was man da eigentlich nutzt – und ob man eine Alternative hätte, wenn der Stecker gezogen wird.

Ein Zahlenbeispiel aus der Praxis

Wie viel im Hintergrund tatsächlich passiert, lässt sich schwer vermitteln, solange es abstrakt bleibt. Deshalb ein konkretes Beispiel aus dem eigenen Netzwerk: Mein Pi-hole läuft seit rund sieben Wochen durch, davon waren drei Wochen Urlaub – das Netz also deutlich ruhiger als im Alltag. In diesem Zeitraum hat Pi-hole über 1,56 Millionen DNS-Anfragen bearbeitet, davon rund 380.000 blockiert. Das sind rund 24 % aller Anfragen, die gar nicht erst rausgingen – Werbung, Tracker, Telemetrie, Malware-Domains.

1
2
3
4
5
6
Pi-hole Gesamtstatistik
-----------------------
Gesamt-Queries : 1567778
Geblockt       : 380393
Blockrate      : 24.26%
Datenbank erstellt : 2026-07-15 13:40:48

Das Bemerkenswerte daran: Im Alltag ist von dieser Blockierquote nichts zu spüren. Webseiten laden, Apps funktionieren, Streaming läuft, Smart Home steuert, Sprachassistenten antworten. Die 300.000 blockierten Anfragen sind für den Nutzer unsichtbar – für die Werbe- und Tracking-Industrie fehlen sie. Und genau das ist der Punkt: Ein Großteil des Datenverkehrs, der ein Gerät verlässt, ist für die Funktion nicht notwendig. Er ist nur für den Hersteller nützlich.

Wer diese Zahl einmal vor sich hat, versteht, dass es nicht um ein paar vereinzelte Tracker geht, sondern um einen kontinuierlichen Datenstrom, der nur deshalb fließt, weil niemand ihn stoppt.

Quelle und Hinweis

Dieser Artikel knüpft an die Beiträge Was wäre – Wenn die Tech-Giganten Europa den Stecker ziehen, Pi-hole und Quad9 am Raspberry Pi und Zwischen Komfort und Privatsphäre an. Die dort skizzierten Überlegungen zur digitalen Abhängigkeit werden hier am Beispiel smarter Lautsprecher und Smart-Home-Infrastruktur konkretisiert.

Die beschriebenen DNS-Anfragen an Amazon- und Google-Domains entsprechen dem typischen Verhalten von Echo- und Nest-Geräten in Heimnetzen, wie sie sich über Pi-hole-Logs nachvollziehen lassen. Herstellerseitige Aussagen zum Umfang der Datenerhebung finden sich in den jeweiligen Datenschutzerklärungen, decken sich aber nicht immer mit dem, was auf Netzwerkebene sichtbar ist.

Quellen

Ähnliche Artikel