DNS Spam zu googleapis.com

[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

[humschti]

Chrome Browser

[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.

[openWB]

Das Display nutzt den chrome browser.
Ist nur die Hintergrund Beleuchtung aus oder hast du es wirklich deaktiviert?

[PeterW]

Das Display nutzt den Chrome Browser? Interessante Architekturentscheidung

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 (198.97 KiB) 126 mal betrachtet

[LutzB]

Das Display nutzt den Chrome Browser? Interessante Architekturentscheidung

Nein, Chromium. Das ist der Standardbrowser im Raspberry Pi OS.

[PeterW]

Das Display nutzt den Chrome Browser? Interessante Architekturentscheidung

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.

[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?

[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)