Seite 1 von 1

DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 7:56 am
von PeterW
Hi zusammen,

mir ist neulich im Adguard DNS (vergleichbar mit PiHole) aufgefallen, dass die openwb neuerdings im Sekundentakt und teils drunter folgende Urls versucht anzurufen:

optimizationguide-pa.googleapis.com
safebrowsing.googleapis.com
update.googleapis.com

Wo kommt hier die Verwendung irgendwelcher Google Librarys her und woher wird das aufgerufen?

Ich hab noch das Skoda SOC Modul in Verwendung, ansonsten läuft die openwb im Grunde "headless", das Display ist auch praktisch immer aus.
IMG_8186.png
(596.23 KiB) Noch nie heruntergeladen

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 8:01 am
von humschti
Chrome Browser

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 8:09 am
von PeterW
Welcher Chrome Browser soll denn auf der openwb Software laufen? Die DNS Anfragen kommen direkt von der openwb und ihrer IP her, nicht von irgendeinem Client.

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 8:14 am
von openWB
Das Display nutzt den chrome browser.
Ist nur die Hintergrund Beleuchtung aus oder hast du es wirklich deaktiviert?

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 8:18 am
von PeterW
Das Display nutzt den Chrome Browser? Interessante Architekturentscheidung :shock:

Ich nutze das Display vielleicht 5 Mal im Jahr, ansonsten über die WebUI oder Home Assistant. Deshalb ist es fast durchgehend ausgeschaltet (aber aktiv)
IMG_8187.jpeg
IMG_8187.jpeg (198.97 KiB) 132 mal betrachtet

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 8:19 am
von LutzB
PeterW hat geschrieben: Mi Mär 25, 2026 8:18 am Das Display nutzt den Chrome Browser? Interessante Architekturentscheidung :shock:
Nein, Chromium. Das ist der Standardbrowser im Raspberry Pi OS.

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 8:23 am
von PeterW
LutzB hat geschrieben: Mi Mär 25, 2026 8:19 am
PeterW hat geschrieben: Mi Mär 25, 2026 8:18 am Das Display nutzt den Chrome Browser? Interessante Architekturentscheidung :shock:
Nein, Chromium. Das ist der Standardbrowser im Raspberry Pi OS.
Ich verstehe, dass es das Rendering der UI stark vereinfacht (bin selbst Softwareentwickler).

Kann man das "Nach Hause Telefonieren" dennoch bitte abstellen? Er soll ja nur lokal die UI anzeigen und keinerlei andere Funktionen nutzen, die Chromium sonst vielleicht verwendet. Sofern das die Chromium API natürlich hergibt.

Im inaktiven Fall (Display aus) am besten überhaupt keine Chromium-Aktivität.

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 9:36 am
von PeterW
Wenn es sich nicht ausstellen lässt, wäre es ggf. eine Option alles nach *.googleapis.com in der /etc/hosts nach 127.0.0.1 umzubiegen.

Wäre sowas über ein openwb Update möglich, oder müsste man dazu selbst per SSH drauf?

Re: DNS Spam zu googleapis.com

Verfasst: Mi Mär 25, 2026 9:56 am
von PeterW
Hier mal was direkt von ChatGPT. Es wäre super, wenn ihr einen Teil davon (Startparsmeter bzw. Policys) oder den Hosts-Ansatz umsetzen könntet:

Wenn Chromium im Kiosk- + Incognito-Modus läuft, versucht er trotzdem im Hintergrund diverse Google-Dienste (z. B. googleapis.com) zu erreichen – etwa für Safe Browsing, Variations, Sync-Checks, etc. Das komplett zu unterbinden geht nur über eine Kombination aus Startparametern, Policies und ggf. Netzwerk-Blocking.

Hier sind die effektivsten Methoden:

Code: Alles auswählen


chromium \
  --kiosk \
  --incognito \
  --disable-background-networking \
  --disable-sync \
  --disable-translate \
  --disable-features=TranslateUI \
  --disable-component-update \
  --disable-domain-reliability \
  --disable-client-side-phishing-detection \
  --no-first-run \
  --no-default-browser-check \
  --disable-default-apps \
  --metrics-recording-only \
  --safebrowsing-disable-auto-update
Besonders wichtig:
--disable-background-networking → stoppt viele Google-Requests
--disable-component-update → verhindert Nachladen von Komponenten
--disable-domain-reliability → blockiert Reporting an Google

2. Policies setzen (empfohlen für Kiosk-Systeme)
Lege eine Policy-Datei an, z. B.:
/etc/chromium/policies/managed/kiosk.json
Inhalt:

Code: Alles auswählen

{
  "MetricsReportingEnabled": false,
  "SafeBrowsingEnabled": false,
  "SafeBrowsingExtendedReportingEnabled": false,
  "SpellcheckEnabled": false,
  "SearchSuggestEnabled": false,
  "NetworkPredictionOptions": 2,
  "AlternateErrorPagesEnabled": false,
  "UrlKeyedAnonymizedDataCollectionEnabled": false
}
👉 Das reduziert weitere Verbindungen zu Google-Endpoints erheblich.

3. Netzwerkseitig blockieren (am zuverlässigsten)
Selbst mit allen Flags kann Chromium noch versuchen, Google-Domains zu kontaktieren. Deshalb:
Option A: /etc/hosts
0.0.0.0 googleapis.com
0.0.0.0 *.googleapis.com
Option B: Firewall (besser)
iptables -A OUTPUT -d googleapis.com -j REJECT
oder DNS-seitig blockieren (z. B. Pi-hole).
👉 Das ist die einzige 100% sichere Methode.
⚠️ Wichtige Nebenwirkungen
Wenn du googleapis.com blockierst:
Safe Browsing funktioniert nicht mehr
Teile von Web-Apps (z. B. Fonts, Maps, Firebase) können brechen
Chrome-Variations/Experiments sind deaktiviert
🧠 Empfehlung (Best Practice)
Für echte Kiosk-Systeme:
Flags + Policies kombinieren
Zusätzlich DNS/Firewall-Blocking
Optional: Chromium ohne Google-Integration nutzen (z. B. ungoogled builds)