Google als Mitleser: Warum so viele Webseiten deinen Besuch verraten

Ich ernte regelmäßig ungläubige Blicke, wenn ich sage:

Wenn ihr ein Google-Konto nutzt – egal in welcher Art – kann euch Google praktisch über das gesamte Internet verfolgen.

Nachfolgend möchte ich die Aussage kurz erläutern.

Sobald eine Webseite Inhalte von Dritten nachlädt, wird dieser Drittanbieter zum stillen Mitleser. Und Google ist als Drittanbieter auf extrem vielen Webseiten eingebunden (Analytics, Ads/DoubleClick, Tag Manager, Fonts, reCAPTCHA, Maps, YouTube, gstatic/CDN usw.). In einer bekannten Messstudie (Top-1-Million-Webseiten) wird Google in Größenordnungen von »nahezu 80 %« als Tracking-/Third-Party-Akteur genannt. Diese Zahl schwankt je nach Zeitraum und Messmethode, aber die Richtung ist seit Jahren stabil: Google taucht sehr häufig auf.

Was dabei oft missverstanden wird: Dazu braucht es nicht zwingend ein »Tracking-Cookie«. Schon der bloße Abruf einer Ressource (Schrift, Bild etc.) von Google verrät etwas. Wenn dein Browser beim Besuch einer Webseite zusätzlich Google-Server kontaktiert, dann sieht Google mindestens: Deine öffentliche IP-Adresse, den Zeitpunkt – und typischerweise auch, von welcher Webseite die Anfrage ausgelöst wurde (über Referrer/Origin-Informationen, je nach Browser-Policy).

So entsteht Tracking in der Praxis

Nehmen wir einen typischen Tagesstart: Jemand öffnet Gmail im Browser oder ein Android-Gerät geht online. Spätestens dann hat Google einen belastbaren Zuordnungspunkt: Dieses Konto (oder diese Session) ist gerade von dieser öffentlichen IP aus aktiv. Ab jetzt ist die entscheidende Frage: Wie oft werden beim normalen Surfen Google-Server nachgeladen?

Und genau hier greift die massive Verbreitung von Google-Komponenten. Viele Webseiten laden beim Aufruf zusätzliche Ressourcen von Google nach, etwa Schriften, Skripte, Analytics, Werbe- oder Messpixel. Sobald das passiert, baut dein Browser eine Verbindung zu Google auf – und das ist technisch zwangsläufig mit einer IP-Übermittlung verbunden. Ohne IP kann der Server nicht antworten.

Warum schon Google Fonts ausreichen

Google Fonts wirken harmlos: »Ist doch bloß eine Schrift.« Technisch ist es aber ein Drittabruf bei Google-Servern. Ein vereinfachter Request sieht ungefähr so aus:

Host: fonts.googleapis.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.spiegel.de/

Wichtig daran:

• Die IP steht nicht im Header drin, wird aber transportbedingt vom Server verarbeitet.
• Moderne Browser senden bei Cross-Site-Requests oft nicht mehr den kompletten Referrer-Pfad, sondern mindestens die Origin (Schema+Domain). Das schützt Details, aber nicht die zentrale Information »du warst gerade auf spiegel.de«. Genau diese Information ist für »wer besucht welche Seite« bereits ausreichend.

Wenn zusätzlich ein Google-Login aktiv ist

Ohne Login sieht Google beim Nachladen von Google-Diensten vor allem »Spuren«: Dein Browser fragt bei Google etwas an, dabei sieht Google Zeitpunkt, deine IP (technisch bedingt) und meist die besuchte Seite als Domain (über Origin/Referrer). Das lässt sich oft zu einem Surfprofil bündeln, aber es ist eher eine Beobachtung auf Ebene von Browser oder Anschlussnetz – nicht sauber einer konkreten Person zugeordnet.

Mit aktivem Login ändert sich das Bild deutlich, weil Google deine IP-Adresse in diesem Moment direkt mit einer laufenden Konto-Sitzung verknüpfen kann: »Konto X ist gerade über IP Y aktiv.« Wenn du danach surfst und auf anderen Webseiten Google-Ressourcen nachgeladen werden, sieht Google diese Abrufe wieder von derselben IP (plus Zeitpunkt und oft die anfragende Domain). Dadurch lassen sich Seitenbesuche deinem Konto zuordnen – selbst dann, wenn nicht immer zusätzliche Kennungen im Request mitsenden. Unterm Strich wird aus »jemand mit IP Y besucht Webseite Z« dann »Konto X besucht Webseite Z«.

Warum »IP-Anonymisierung« das Grundproblem nicht löst

In Diskussionen wird gern auf »IP-Anonymisierung in Analytics« verwiesen. In GA4 ist das tatsächlich entschärft: Google sagt, dass IP-Adressen nicht geloggt oder gespeichert werden und – für EU-Nutzer – vor dem Logging verworfen werden. Das ist eine Verbesserung bei der Speicherung und Auswertung innerhalb von Analytics. Am Grundmechanismus ändert es aber wenig: Wenn Webseiten Google-Komponenten einbinden, müssen Browser diese Ressourcen bei Google abrufen. Dabei sieht Google die IP zwangsläufig kurzfristig (sonst keine Antwort) und bekommt weiterhin verwertbare Signale wie Zeitpunkt und typischerweise mindestens die anfragende Domain (Origin) plus Browser-Metadaten.

Unterm Strich: GA4 kann IP-Speicherung reduzieren, aber es verhindert nicht, dass Google über eingebundene Drittressourcen in großem Maßstab mitbekommt, welche Webseiten gerade besucht werden, und diese Signale zusammenführen kann.

Selbst prüfen, wie verbreitet Google ist

Wer das einmal live sehen will, braucht keinen Spezialaufbau: Browser-Entwicklertools öffnen (Netzwerk-Tab), Seite neu laden, nach »google«, »gstatic«, »doubleclick«, »googletagmanager«, »fonts« filtern. Je nachdem, was dort auftaucht, bekommt man ein sehr gutes Gefühl dafür, wie oft beim ganz normalen Surfen Drittverbindungen zu Google entstehen.

Was kann man dagegen tun?

Für Webseitenbetreiber ist der Hebel am größten: Lokal hosten (bspw. Schriften), unnötige Drittanbieter vermeiden, Einbettungen (Maps/YouTube/reCAPTCHA) kritisch prüfen oder erst nach echter Zustimmung laden.

Als Besucher bleibt es bei Schadensbegrenzung: Tracking-Blocker (uBlock Origin), strikte Trennung von Google-Login (separates Profil/Container), und konsequentes Blocken von Drittressourcen dort, wo es praktikabel ist. Das ist nicht »perfekt«, aber es reduziert die Zahl der Kontakte zu Google-Servern.

»Wir respektieren Ihre Privatsphäre«: Warum ich bei solchen Sätzen skeptisch werde

»Wir respektieren Ihre Privatsphäre.« »Der Schutz Ihrer Daten ist uns wichtig.« Solche Sätze stehen inzwischen überall: Im Cookie-Banner, beim ersten Start einer App, ganz oben in der Datenschutzerklärung. Sie klingen beruhigend – und genau deshalb sind sie so beliebt. Als Aussage haben sie allerdings praktisch keinen Wert. Sie sind für viele kaum einzuordnen und sagen ohne weitere Details fast nichts aus – weil sie weder konkret benennen, welche Daten wofür verarbeitet werden, noch welche technischen Maßnahmen dahinterstehen.

Datenschutz zeigt sich in Entscheidungen

Datenschutz ist kein Gefühl und keine Haltung, die man in zwei Zeilen erklären kann. Datenschutz ist eine Summe aus Entscheidungen: Welche Daten werden überhaupt erhoben? Welche sind wirklich erforderlich? Was bleibt lokal, was wird übertragen? Wie lange wird gespeichert? Welche Dritten sind eingebunden? Und vor allem: Hat man als Nutzer tatsächlich eine Wahl, oder wird diese Wahl so gestaltet, dass am Ende doch die Einwilligung herausfällt? Diese Fragen beantwortet ein Satz wie »Wir respektieren Ihre Privatsphäre« nicht. Er ersetzt sie.

Man merkt das besonders schnell dort, wo es konkret wird: Beim Cookie-Banner auf Webseiten. Ein Anbieter kann im Banner behaupten, Privatsphäre zu respektieren – und gleichzeitig das Ablehnen verstecken, erschweren oder mit Nachteilen verknüpfen. Die Gestaltung sagt dann mehr als jede Formulierung. Wenn »Akzeptieren« auffällig und bequem ist, während »Ablehnen« erst nach mehreren Klicks erreichbar wird, dann ist die Richtung klar: Es geht um Zustimmung, nicht um Privatsphäre.

Ähnlich ist es bei Apps. Auch hier werden gern warme Worte vorgeschoben, während im Hintergrund ein ganzer Baukasten aus Drittanbieter-SDKs läuft: Analytics, Marketing, Crash-Reporting, A/B-Tests, Remote-Konfiguration. Das muss nicht immer böswillig sein, ist aber ein Muster: Daten fließen nicht nur zum eigentlichen Anbieter, sondern in ein Ökosystem. Je mehr Dritte beteiligt sind, desto weniger Kontrolle bleibt übrig – und desto schwerer wird es, überhaupt noch sauber zu erklären, wer was bekommt und warum.

Wenn alles unter »Optimierung« fällt

Dazu passt die typische Unschärfe in Datenschutzerklärungen. Begriffe wie »Verbesserung unserer Dienste« oder »besseres Nutzererlebnis« sind bequem, weil sie alles abdecken können. Für Nutzer sind sie wertlos, weil sie keine Grenze ziehen. Datenschutz, der ernst gemeint ist, wird konkret: Mit klaren Zwecken, nachvollziehbaren Datenkategorien, kurzen Speicherfristen und einem Datenfluss, den man plausibel erklären kann, ohne dass am Ende alles unter »Optimierung« fällt.

Etikett statt Beleg

Wer Privatsphäre wirklich respektiert, muss im Idealfall gar keinen Consent-Zirkus veranstalten. Ein Banner wird meist dort gebraucht, wo Tracking, Marketing-Tools oder andere »Überwachungs«-Bausteine eingebunden sind, die ohne Einwilligung nicht laufen dürfen. Wer dagegen datensparsam arbeitet, kommt häufig ohne Cookie-Banner aus – oder braucht höchstens einen kurzen Hinweis für technisch notwendige Cookies.

Datenschutz, der diesen Namen verdient, zeigt sich deshalb weniger in wohlklingenden Sätzen, sondern in Entscheidungen, die man nachprüfen kann: Keine unnötigen Drittanbieter, keine heimlichen Identifier, Berechtigungen nur dort, wo sie wirklich erforderlich sind, und Speicherfristen, die man nachvollziehbar begründen kann. Das lässt sich technisch kontrollieren – im Datenfluss, in den Verbindungen nach außen, notfalls auch mit einem Netzwerkmitschnitt.

Und damit ist klar, was die Überschrift meint: Der Satz »Wir respektieren Ihre Privatsphäre« ist häufig weniger ein belastbares Versprechen als ein Etikett. Datenschutz ist in vielen Unternehmen längst Teil der Außendarstellung – etwas, das gut klingen soll und Vertrauen erzeugt. Genau dieses Vertrauen führt dann oft dazu, dass schneller geklickt wird und weniger Aufmerksamkeit darauf fällt, was im Hintergrund tatsächlich passiert.

Natürlich kann so ein Satz im Einzelfall darauf hindeuten, dass intern tatsächlich sauber gearbeitet wird. In der Praxis bleibt es aber oft bei der Formulierung: Man schreibt »datenschutzfreundlich«, während sich an Tracking, Drittanbietern und Datensammeln wenig ändert. Echte Privatsphäre entsteht nicht durch Worte, sondern durch konkrete Entscheidungen – vor allem durch Verzicht: Weniger Tracker, weniger Daten, weniger externe Dienstleister. Und genau das erledigt sich nicht mit einem hübschen Satz.

DHL-Packstation-Sicherheitslücke: »Überraschungsei« im Schließfach

Am Wochenende wollte ich zwei kleine Pakete an einer DHL-Packstation abgeben. Einlegen, Tür zu, fertig. Nach dem Einlegen des ersten Pakets stürzte die Packstation jedoch ab. Bildschirm ging kurz aus, dann ein Neustart. Das Paket war zu diesem Zeitpunkt bereits im Fach. Toll, dachte ich. Und nun?

Ich startete einfach einen neuen Vorgang – und die Packstation öffnete plötzlich genau das Fach, in das ich kurz zuvor Paket Nummer eins gelegt hatte. Ich hätte die Sendung problemlos wieder entnehmen können. Kein Hinweis auf eine Störung, keine Warnung »Fach belegt«, keine zusätzliche Absicherung. Das Fach ging auf, als wäre es leer oder als hätte es nie einen vorherigen Vorgang gegeben.

For the record: Eine Packstation ist im Kern ein Schließfachsystem, das fremdes Eigentum verwaltet. Der entscheidende Punkt ist deshalb nicht, ob ein Absturz vorkommen kann – Technik kann ausfallen. Der entscheidende Punkt ist, was danach passiert. Und hier wirkt es, als könne die Packstation in bestimmten Störfällen den Zustand verlieren: Das System weiß nicht mehr zuverlässig, ob ein Fach belegt ist. Oder schlimmer: Es behandelt ein Fach als »frei«, obwohl darin bereits eine Sendung liegt – und teilt es einfach erneut zu.

Das Ergebnis ist ein faktischer Zugriff auf fremde Pakete ohne jede Hürde. Dafür braucht es keinen Hack, keine kriminelle Energie auf Spezialniveau, keine Manipulation – nur den nächsten Einlieferungsprozess. Im schlechtesten Fall erwischt das nicht einmal denselben Nutzer, sondern den Nächsten, der zufällig an dieser Packstation einliefert. Und dann liegt das Problem nicht bei »Fehlbedienung«, sondern beim Design: Wenn eine Störung dazu führen kann, dass ein befülltes Fach später wie ein leeres Fach behandelt und geöffnet wird, ist das eindeutig eine Sicherheitslücke.

Man kann es auch anders formulieren: Ein System, das nach einem Fehler lieber ein Fach zu viel öffnet als eines zu wenig, ist falsch konstruiert. Bei einem Schließfach, in dem es um Eigentum, Haftung und Vertrauen geht, muss der Standard im Zweifel »geschlossen« sein – nicht »wird schon leer sein«. Genau dieses Vertrauen wird durch solche »Überraschungsei-Momente« zerstört: Heute ist es das eigene Paket, das plötzlich wieder offen vor einem liegt. Morgen ist es vielleicht das Paket eines Fremden, das man gar nicht sehen dürfte.

Ist der Messenger Signal »Big Tech« – oder nicht?

Die Frage kommt regelmäßig – und sie kommt fast immer mit einem Unterton: Wer Signal nutzt, ist doch trotzdem bei »den Großen«. Schließlich läuft Signal über Infrastruktur von Amazon, Google, Microsoft und Cloudflare. Und wenn Big Tech im Spiel ist, kann das ja per Definition nicht gut sein. So die Kurzform.

Das Problem: Diese Sichtweise wirft zwei Ebenen in einen Topf. Ein Messenger ist nicht automatisch »Big Tech«, nur weil er Server anmietet. Und ein Dienst ist nicht automatisch »sauber«, nur weil er irgendwo auf eigener Hardware läuft. Wer ernsthaft über Signal sprechen will, muss trennen: Was ist Signal als Organisation und Produkt – und was ist Signal als Dienst, der im Internet betrieben werden muss?

Was »Big Tech« eigentlich meint

Mit »Big Tech« ist in der Regel nicht einfach »groß« gemeint, sondern ein Geschäftsmodell und ein Machtapparat: Plattformen, die durch Ökosysteme, Lock-in und Datenauswertung dominieren. Werbe- und Trackinglogik, Profilbildung, Datenhandel, Kontrolle über Schnittstellen, Abhängigkeiten. Big Tech ist nicht nur eine Frage der Größe, sondern des Geschäftsmodells: Womit verdient ein Anbieter Geld, und was muss er dafür über seine Nutzer wissen?

Und hier wird es interessant, denn Signal passt nicht in dieses Muster.

Signal ist nicht Big Tech

Signal verkauft keine Werbung, baut kein soziales Netzwerk, betreibt keinen App-Store, keine Cloud-Suite, kein Tracking-Ökosystem. Signal lebt nicht davon, immer mehr Daten zu sammeln und immer mehr Auswertungen zu fahren. Im Gegenteil: Das Designziel ist, dass der Betreiber möglichst wenig weiß und möglichst wenig wissen kann. Das ist keine PR-Floskel, sondern ein Architekturprinzip, das man bei Messenger-Vergleichen nicht wegdiskutieren sollte.

Natürlich ist Signal nicht perfekt. Die Telefonnummer war lange ein Reibungspunkt (und ist es für viele immer noch), weil sie eine Brücke zur realen Identität sein kann. Aber: Das ist eine Produktentscheidung rund um Contact-Discovery und Alltagstauglichkeit – nicht das klassische Big-Tech-Muster »wir brauchen dich als Datensatz«. Signal versucht erkennbar, diesen Konflikt zu entschärfen, ohne den Messenger in ein Nerdprojekt zu verwandeln, das am Ende nur fünf Leute nutzen.

Wer also fragt, ob Signal Big Tech ist, muss sich ehrlich machen: Signal ist kein Big-Tech-Konzern. Es ist ein Messenger, der sich – im Rahmen dessen, was heute für Massenkommunikation realistisch ist – stark an Datensparsamkeit orientiert.

Der wunde Punkt: Signal nutzt Big-Tech-Infrastruktur

Und trotzdem ist die Kritik nicht aus der Luft gegriffen: Ja, Signal nutzt Infrastruktur großer Anbieter. Wer das pauschal ablehnt, hat einen nachvollziehbaren Standpunkt – denn am Ende fließt Geld an Konzerne, die viele aus Datenschutz- und Souveränitätssicht kritisch sehen. Außerdem entsteht eine Abhängigkeit: Wenn zentrale Infrastruktur wackelt, wackelt auch der Dienst.

Das ist aber etwas anderes als die Aussage »Signal ist Big Tech«. Treffender wäre: Signal ist von Big Tech abhängig, weil der Betrieb eines globalen Messengers Skalierung, Verfügbarkeit und DDoS-Schutz verlangt. Und genau hier liegt das eigentliche Dilemma: Es geht nicht nur um Signal. Es geht um die Frage, wie stark das Internet inzwischen auf wenige Infrastruktur-Giganten konzentriert ist – und wie schwer es geworden ist, diese Abhängigkeit komplett zu umgehen, ohne massive Nachteile bei Stabilität und Nutzerfreundlichkeit zu akzeptieren.

Man kann diese Abhängigkeit kritisieren, man sollte sie sogar kritisieren. Aber man sollte sie nicht als Totschlagargument missbrauchen, um Signal in die gleiche Schublade wie Meta zu stecken. Das ist bequem, aber sachlich falsch.

Warum bei Messengern oft »pragmatisch« gewinnt

An dieser Stelle kommt meist der nächste Vorwurf:

Du empfiehlst bei Social Media Dezentralität (Fediverse), aber bei Messengern plötzlich zentrale Lösungen wie Signal oder Threema – wie passt das zusammen?

Das passt dann zusammen, wenn man versteht, dass Social Media und Messenger unterschiedliche Probleme lösen. Social Media ist öffentliche Kommunikation, Reichweite, Diskursraum, Moderation, Regeln, Manipulation durch Algorithmen, Macht über Sichtbarkeit. Dort ist Dezentralität ein Hebel gegen Plattformkontrolle.

Messenger sind dagegen private, geschlossene Kommunikation im Alltag. Für die meisten zählt: Es muss funktionieren, es muss verständlich sein, Kontakte müssen auffindbar sein, und Sicherheit muss standardmäßig aktiv sein – nicht als Option für Fortgeschrittene. Wenn du für deinen Familienchat erst einen Server auswählen, Zuständigkeiten verstehen und Client-Kompatibilitäten diskutieren musst, hast du in der Praxis schon verloren. Dann bleibt WhatsApp – und alle theoretischen Vorteile sind wertlos.

Deshalb ist Signal für viele Menschen nicht die »perfekte« Lösung, sondern die umsetzbare. Der beste Messenger ist nicht der mit den meisten Häkchen in einer Vergleichstabelle, sondern der, der sicher und datenschutzfreundlich ist – und den deine Kontakte auch wirklich nutzen.

Also: Big Tech oder nicht?

Wenn du unter »Big Tech« den typischen Mix aus Datenauswertung, Tracking, Plattformmacht und Werbeökonomie verstehst, dann ist Signal nicht Big Tech. Signal steht – trotz Schwächen – konzeptionell auf der anderen Seite: Möglichst wenig Daten, möglichst wenig Wissen, möglichst wenig Angriffsfläche durch Geschäftsmodell.

Wenn du unter »Big Tech« aber jede technische Berührung mit Amazon, Google, Microsoft oder Cloudflare verstehst, dann hängt Signal zwangsläufig »an Big Tech dran«. Das ist ein valider Kritikpunkt – nur richtet er sich nicht gegen Signal als Messenger-Idee, sondern gegen den Zustand des Netzes und die Konzentration von Infrastruktur.

Die ehrliche Antwort lautet deshalb: Signal ist nicht Big Tech – aber Signal kommt aktuell nicht ohne Big-Tech-Infrastruktur aus. Wer daraus ein Schwarz-Weiß machen will, landet schnell bei Fanboy-Debatten und Fake-News. Wer dagegen nüchtern bleiben will, kann beides gleichzeitig sagen: Signal ist für viele eine sehr gute WhatsApp-Alternative, und trotzdem bleibt die Infrastruktur-Abhängigkeit ein Makel, über den man sprechen darf – ohne gleich die gesamte Sicherheitsarchitektur zu negieren.

Und genau da liegt der Punkt, den viele Diskussionen konsequent verfehlen: Nicht »Signal verteufeln« oder »Signal schönreden«, sondern sauber benennen, was Signal löst (alltagstaugliche, standardmäßig sichere Kommunikation) und was Signal nicht löst (die strukturelle Abhängigkeit des Netzes von wenigen Infrastruktur-Giganten).

Google Pixel 9a: Gerätevergabe an Unterstützer – Februar 2026

Aufgepasst: Unter allen Unterstützerinnen und Unterstützern wird ein Google Pixel 9a mit GrapheneOS vergeben. Wer den Kuketz-Blog im Februar 2026 per Banküberweisung unterstützt, wird berücksichtigt. Anfang März lasse ich eine Person per Zufall ermitteln und veröffentliche anschließend die entsprechenden Details (keine Rückschlüsse auf eine Person möglich), damit sich die Person bei mir melden kann. Danach wird das Gerät verschickt.

Es handelt sich um ein neues Gerät (Google Pixel 9a), das nur ausgepackt wird, um das alternative Android-System GrapheneOS zu installieren:

• 6.3 Zoll Display / 1080 × 2424 pOLED (60-120 Hz)
• 8 GB RAM
• 128 GB Speicherkapazität
• 48 MP Weitwinkelkamera / 13 MP Ultraweitwinkelkamera / 13 MP Frontkamera
• Google Tensor G4 (Titan M2-Sicherheitschip)
• 5.100 mAh Akku (kabelloses Laden)
• 5G (eSIM kompatibel)
• Besonderheit: 7 Jahre (Sicherheits-)Updates (bis Frühjahr 2032)