Der Smart-TV im Wohnzimmer ist ein Knoten der KI-Scraping-Ökonomie

 (blog.includesecurity.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das in Verbraucher-Apps eingebettete Bright Data SDK verwandelt mit Zustimmung der Nutzer ein Smartphone oder einen Smart-TV in einen Residential-Proxy-Ausgangsknoten und leitet das Web-Scraping-Traffic von Kunden über private IP-Adressen
  • Residential Proxys sind ein Umgehungsmittel, um Zielseiten über die IP-Adresse eines zahlenden Privatkunden zu erreichen, in einer Umgebung, in der Cloudflare, DataDome, HUMAN und andere Anfragen von bekannten Cloud-IP-Adressen drosseln oder blockieren
  • Vernetzte Fernseher haben keine Akku-Beschränkungen, sind ständig mit Wi‑Fi verbunden und laufen im Standby 24/7, wodurch sie als Proxy bessere Bedingungen für ständige Verfügbarkeit und unbeaufsichtigten Betrieb bieten als Smartphones
  • Das iOS-SDK erhält über einen nicht authentifizierten Konfigurationsendpunkt Leerlaufkriterien, Bandbreitenlimits und Partnerlisten und öffnet einen WebSocket-Peer-Tunnel, um Geräte-Status-Telemetrie und cmd_tun-Scraping-Aufgaben zu verarbeiten
  • Die Abwehr konzentriert sich auf DNS-Blocking von proxyjs.* und clientsdk.*, SNI-Filtering, Erkennung von TLS-Zertifikats-Fingerprints und MDM-Scans von App-Binaries; use_netifs unter iOS ist eine Einschränkung, die VPN-basierte Sichtbarkeit umgeht

Überblick

  • Unabhängig vom Widerstand auf Community-Ebene gegen den Bau von Rechenzentren zur Steigerung von KI-Kapazitäten gibt es eine Struktur, bei der Geräte im Zuhause für verteilte Datenerfassung zum KI-Training genutzt werden können
  • Bright Data verkauft Zugang zu einem Residential-Proxy-Netzwerk mit über 400 Mio. privaten IP-Adressen, über das Kunden ihr Web-Scraping-Traffic routen; die Quelle sind in Verbraucher-Apps eingebettete SDKs
  • Das betreffende SDK verwandelt mit Zustimmung der Nutzer Smartphones oder Smart-TVs in Ausgangsknoten; untersucht werden die Funktionsweise des SDK, die Verbreitungsplattformen und warum internetfähige Fernseher gut für Web-Scraping-Proxys für KI-Modelle geeignet sind

Warum das jetzt wichtig ist

  • KI-Unternehmen sind für Pretraining, Suche und Search Augmentation, Agent-Grounding und Suchfunktionen auf per Web Scraping gewonnene Inhalte angewiesen
  • Das moderne Web ist keine Umgebung mehr, die sich aus Rechenzentren leicht scrapen lässt, und Cloudflare, DataDome, HUMAN drosseln oder blockieren Anfragen von bekannten Cloud-IP-Adressen
  • Die Alternative sind Residential Proxys, die Zielseiten über die IP-Adresse eines zahlenden Privatkunden erreichen, etwa über einen Anschluss von Comcast- oder T-Mobile-Abonnenten
  • Ein Zitat aus einem Bericht von Krebs vom Oktober 2025 lautet: „Der Überfluss an Proxys aus Aisuru und anderen Quellen befeuert groß angelegte Datenernte-Bemühungen, die mit mehreren KI-Projekten verbunden sind.“
  • Akademische Messungen, die bis 2019 zurückreichen, kommen zu dem Ergebnis, dass solche Netzwerke überwiegend missbraucht werden; auch das FBI veröffentlichte Anfang dieses Jahres eine offizielle Warnung
  • Der Großteil der bisherigen Berichterstattung konzentriert sich auf illegale Quellen für Residential Proxys, etwa Botnets wie Aisuru und Kimwolf, trojanisierte Apps wie PROXYLIB oder vorinfizierte IoT-Hardware wie IPIDEA
  • Die legale Angebotsseite wurde vergleichsweise wenig untersucht; Bright Data bewirbt sich nach eigenen Marketingangaben als weltweit größtes Residential-Proxy-Netzwerk und wirbt mit „150M+ IPs“, die auf zustimmungsbasierten SDKs in Partner-Apps beruhen

Warum vernetzte Fernseher ideale Proxys sind

Faktor Smartphone Smart-TV / CTV
Stromversorgung Die meiste Zeit des Tages Akkubetrieb Ständig am Strom
Netzwerk Wi‑Fi + Mobilfunk Immer Wi‑Fi, hohe Geschwindigkeit
Laufzeit Sporadisch 24/7 im Standby
Bandbreitenlimit Niedrig, Mobilfunkbeschränkungen Faktisch unbegrenzt
Aufmerksamkeit der Nutzer Aktiv genutzt Oft unbeaufsichtigt
Consent-UI Text auf Smartphone-Bildschirm Text, der mit den Pfeiltasten der TV-Fernbedienung navigiert wird
Aufsicht durch Unternehmen/Familie Höher, etwa durch MDM oder Mobile EDR Praktisch keine
  • Fernseher erreichen keinen Akkustand von 1 %, wechseln nicht ständig zwischen Wi‑Fi-Netzen und werden nicht gesperrt, während der Nutzer schläft
  • Einige Partner-Publisher legen ihre Beziehung zu Bright Data in Datenschutzrichtlinien offen; ein Beispiel ist die Datenschutzrichtlinie von PlayWorks
  • Offenlegungen in Datenschutzrichtlinien sind kein geeigneter Kontrollpunkt für Fernseher: Rechtstexte lassen sich mit den Pfeiltasten einer Fernbedienung nur schwer scrollen, und In-App-Consent-Dialoge vermitteln strukturell nicht, dass zahlende Bright-Data-Kunden Scraping-Traffic über den privaten Internetanschluss des Nutzers routen
  • Der von The Verge dokumentierte Opt-in-Bildschirm der Roku-App Petflix verwendet die Formulierung, dass Bright Data „gelegentlich die ungenutzten Ressourcen und die IP-Adresse Ihres Geräts verwenden darf, um öffentliche Webdaten aus dem Internet herunterzuladen, damit Sie weniger Werbung sehen und kostenlos genießen können“
  • Der Petflix-Dialog verwendet zwar den Ausdruck „gelegentlich“, doch die öffentlich abrufbare SDK-Konfiguration mit max_bw_monthly_wifi: 200,000,000,000 setzt ein monatliches Standardbudget von 200 GB über Wi‑Fi

Von Bright Data als Partner benannte Ziele

  • Bright Data stellt einen Partner-Manifest-Endpunkt bereit, den jeder ohne Authentifizierung abrufen kann
  • Identifikationsmerkmale mit hoher Vertrauenswürdigkeit auf Basis öffentlicher Quellen
Partner ID Entity Größenordnung
playworks_digital PlayWorks Digital Ltd Über 400 CTV-Spieltitel, Reichweite von rund 250 Mio. TV-Haushalten über Comcast, Sky, Cox, LG, Samsung, Vizio und Roku
cloudtv CloudTV Integriert über mehr als 125 TV-Marken und über 15 OEMs hinweg
longvision_media_hong_kong_co_limited Longvision Media HK (LongTV) 5 Mio. OTT-Nutzer in Hongkong und Malaysia
viber_media_s_r_l Viber Media S.à r.l. (Rakuten) 250 Mio. bis 820 Mio. monatliche Nutzer des Viber-Messengers
supercent_inc Supercent 2023 nach Downloads der führende südkoreanische Mobile Publisher
moonfrog_labs_private_limited Moonfrog Labs Allein Teen Patti Gold mit rund 10 Mio. MAU, für 90 Mio. US-Dollar übernommen
hola_networks Hola Networks Das Mutterunternehmen in der Unternehmensgeschichte von Bright Data; laut früheren Marketingangaben von Hola lag die Spitzenzahl der Nutzer im Bereich von mehreren zehn Millionen bis über 100 Mio.
  • desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp sind im Manifest enthalten, lassen sich aber nur schwer einer öffentlichen Quelle zuordnen
  • bright_screensavers, bright_videos, brightdata sind Apps von Bright Data selbst
  • Dass in den Bright-Data-Einstellungen ein Name auftaucht, deutet darauf hin, dass es zu irgendeinem Zeitpunkt eine Integration gegeben haben könnte, ist aber kein direkter Beleg dafür, dass die aktuell von einem bestimmten Publisher verbreitete App in der Produktionsumgebung ein SDK enthält
  • Was die Partnerliste direkt belegt, ist, dass Bright Data diese Liste über einen öffentlichen Endpoint ohne Authentifizierung verbreitet und dass mindestens drei CTV-orientierte Anbieter wie PlayWorks, CloudTV und Longvision Nutzergeräte als Residential-Proxy-Ausgangsknoten monetarisiert haben
  • PlayWorks nennt in eigenen Marketingunterlagen CTV-Distribution über wichtige TV-Plattformen und ISPs hinweg sowie Reichweiten im Umfang von Hunderten Millionen Haushalten
Anzeige

Wie das Bright-Data-SDK Nutzergeräte in Residential-Proxy-Ausgangsknoten verwandelt

  • Das Bright-Data-SDK ist ein öffentlich dokumentiertes kommerzielles Produkt mit SDK-Integrationsdokumentation für Publisher und einer JavaScript-Variante für das Web

  • Die Analyse basiert auf Reverse Engineering eines eingesetzten iOS-Frameworks und 30 Tagen Laufzeit-Traffic-Messung

  • Das SDK wird in Partner-Apps als iOS-Framework brdsdk.framework ausgeliefert

  • Konfiguration ohne Authentifizierung

    • Das SDK ruft bei jedem Start die folgende Anfrage auf
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • Der Endpunkt funktioniert ohne nennenswerte Authentifizierung, und der Server prüft nur zwei Query-Parameter: appid, die Bundle-ID der App, und ver, den SDK-Versionsstring
    • Wenn man die in einem App-Store-Eintrag der Partner-App auffindbare Bundle-ID, den SDK-Versionsstring und eine beliebig erzeugte UUID angibt, liefert der Server dieselbe Konfiguration zurück wie an ein echtes Gerät
    • Die Antwort enthält Feature-Flags, Schwellenwerte zur Idle-Erkennung wie Akkustand, CPU-/Speicherobergrenzen und WLAN-/Mobilfunkregeln, länderspezifische Bandbreitenstufen sowie ein Partner-Manifest
    • In der Konfiguration finden sich Idle-Regeln, unter denen ein Gerät die Berechtigung zum Traffic-Relay erhält, ein Flag zum Routing von Peer-Traffic um VPNs herum, eine Map zur Verknüpfung plattformübergreifender Installationen zu einer einzigen Identität sowie länderspezifische Bandbreitenlimits

  • Peer-Tunnel

    • Nach dem Abruf der Konfiguration öffnet das SDK eine dauerhafte WebSocket-Verbindung zu
    • wss://proxyjs.brdtnet.com:443
    • Dieser Hostname löst zum Zeitpunkt der Erstellung auf die AWS-Global-Accelerator-IPs 3.33.193.183, 15.197.193.114 auf
    • Das TLS-Zertifikat lautet auf CN=*.luminatinet.com; Luminati Networks war der Unternehmensname von Bright Data vor 2018
    • Auch nach dem Rebranding 2018 verwendet die aktive SDK-Infrastruktur Legacy-Zertifikate, und luminatinet.com- oder brdtnet.com-Traffic ist kein Hinweis auf Bright-Data-Nutzung auf Kundenseite, sondern ein Erkennungsmerkmal der Peer-Tunnel-Ebene
    • Die aktuellen Proxy-Dienste für Kunden laufen unter Domains der Marke brightdata.com, daher steht luminatinet.com- bzw. brdtnet.com-Traffic im Netzwerk für die Peer-Tunnel-Ebene
    • Der Server identifiziert sich selbst als uWebSockets: 20
    • Der Peer-Endpunkt verlangt für das Upgrade keine Authentifizierung, akzeptiert nach gültigem TLS ein WebSocket-Upgrade und sendet sofort einen Frame auf Anwendungsebene, der die öffentliche IP des Clients zurückliefert
    • Handshake-Ablauf
      1. Server → Client tunnel_init: erstellt eine Sitzung und gibt die öffentliche IP des Clients zurück
      1. Server → Client cid_set: weist eine Sitzungs-Tracking-ID im Format <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> zu, die mit dem cid-Feld in der Telemetrie realer Geräte übereinstimmt
      1. Server → Client status_get: fragt Idle-Zustand, Akku, Netztyp und verfügbare Bandbreite des Geräts ab, und das Gerät antwortet mit fortlaufender Telemetrie wie idle, wifi_connected, mobile_connected, mobile_type, roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid, sdk_version, platform, cid
      Anzeige
      1. Nach Abschluss des Handshakes kann die Job-Matching-Schicht des Servers cmd_tun-Frames pushen, wenn das Gerät einen günstigen Zustand meldet; das SDK führt diese dann als HTTP-Anfragen an Drittseiten aus, wobei die Residential-IP des Nutzers als Ausgangsadresse dient
    • Alle Frames des WebSocket bestehen aus Plain-JSON mit festem Envelope
    • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
    • Aus dem Binärcode extrahierte und in realer Kommunikation bestätigte Befehle
    • | Richtung | cmd | Zweck |
    • |---|---|---|
    • | Server → Client | tunnel_init | Sitzung öffnen, öffentliche IP zurückgeben |
    • | Server → Client | cid_set | Sitzungskennung zuweisen |
    • | Server → Client | status_get | Idle-, Akku- und Bandbreitenstatus des Geräts abfragen |
    • | Server → Client | cmd_tun / tun | Scraping-Job zustellen |
    • | Server → Client | dns | DNS-Auflösung für Ziel anfordern |
    • | Server → Client | consent | Einwilligungsstatus anfordern |
    • | Client → Server | status_send | periodischer Heartbeat zum Gerätestatus |
    • | Client → Server | tun_report / tun_ack / tun_fin | Antworten zum Lebenszyklus des Relay-Jobs |
    • | Client → Server | tunnel_init_decline | Sitzung ablehnen |
    • | Client → Server | logs | Diagnoselogs an den Server senden |
    • Es gibt weder Nachrichtensignaturen noch HMAC, Client-Zertifikate oder Geräte-Attestation; tatsächlich trennt nur die TLS-Ebene zusammen mit dem IP-Reputationsfilter des Servers die Peers, die echte Jobs erhalten
    • Für Leser, die mit dem Design kommerzieller Malware-Protokolle vertraut sind, liegt das Sicherheitsniveau praktisch unter dem eines typischen C2

  • Bedingungen, unter denen das SDK „idle“ annimmt

    • Die Konfiguration legt Regeln für Gerätezustände fest, unter denen der Traffic anderer weitergeleitet werden darf
    "idle_metrics": {
  "ignore_screen_on": true,
  "ignore_on_call": true,
  "max_bw_ratio": 1,
  "min_battery": 0.2,
  "wifi_on_battery": true,
  "min_battery_wifi": 0.2,
  "max_cpu_usage": 70,
  "max_mem_usage": 90,
  "mem_screen_off": true,
  "idle_timeout": 30,
  "not_idle_timeout": 10
}
    • Aufgrund der Flags ignore_screen_on und ignore_on_call bedeutet „idle“ nicht, dass der Nutzer sich vom Gerät entfernt hat, sondern dass CPU, Speicher und Akku innerhalb der SDK-Schwellenwerte liegen
    • Auch wenn der Nutzer telefoniert oder aktiv auf den Bildschirm schaut, gilt das für Relay-Zwecke als Idle-Zustand

  • Plattformübergreifende Identitätsverknüpfung

    • In der Konfiguration existiert die folgende dual_pairing-Map
    Anzeige
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • Diese Map ist eine serverseitige Verknüpfungsstruktur, die iOS-, Windows- und macOS-Installationen derselben Marke zu einer einzigen Entität zusammenfasst
    • Das Feld http3_enabled: true ist ein Flag für QUIC-basierten Peer-Transport; künftige Versionen könnten den Peer-Tunnel von TCP/443 auf UDP/443 verlagern
    • Für Verteidiger, die WebSockets per TCP-Connection-Tracking erkennen, könnte diese Erkennung bei einem Wechsel auf UDP/443 versagen

  • Umgehung von Inspektion

    • Das Flag use_netifs: true in der SDK-Konfiguration ist die Bedingung dafür, dass der Binärcode des SDK NWConnection über bestimmte vorgeschriebene Interfaces statt über den Standardpfad des Systems aufbaut
    • Die vorgeschriebenen Interfaces sind bei WLAN en0 oder bei Mobilfunk pdp_ip0
    • Unter iOS umgeht dieser Ansatz das tun0-Interface eines konfigurierten VPN vollständig; selbst wenn anderer HTTPS-Traffic der App durch das VPN läuft, passiert der Peer-Tunnel nicht das vom Nutzer konfigurierte VPN

  • Die Forschungsumgebung für transparente TLS-Abfangung erfasste zwar alle HTTPS-Aufrufe des SDK, konnte aber den Peer-Tunnel zu proxyjs.brdtnet.com:443 nicht erfassen, obwohl Port 443 explizit an den Inspektor umgeleitet wurde

    • Die Umgehung nutzt Apples dokumentierte API NWParameters.requiredInterface
    • Das SDK verwendet zwei unabhängige Inspektions-Umgehungen
    • Control Plane: Das Abrufen der Konfiguration und Telemetrie-Pings basieren auf den CFHTTPMessage-Primitives von CFNetwork statt auf URLSession oder NSURLConnection, wodurch auf URLSession-Ebene übliche Instrumentierung, Swizzling, Network Extensions und URLProtocol-Subklassen in Mobile-App-Sicherheitstools wirkungslos werden, während System-Proxys weiterhin respektiert werden und Forschende zur TLS-Abfangung somit Sichtbarkeit behalten
    • Data Plane: Der Peer-Tunnel basiert auf NWConnection, wobei die physische Schnittstelle als erforderliche Schnittstelle festgelegt wird; dadurch werden VPNs ausgehebelt und sichergestellt, dass das Scraping über Residential IPs läuft
    • Für Sicherheitsteams, die MDM, unternehmensweite VPN-basierte Traffic-Inspektion oder Jugendschutz auf Heimroutern einsetzen, ist ausgerechnet der sensibelste Kanal so konzipiert, dass er die Sichtbarkeitsschicht umgeht

Länderspezifische Stufen

  • In den Einstellungen gibt es länderspezifische Bandbreiten-Schwellenwerte.
Anzeige
Land Minimale Batterie für Relay Tägliches Limit Monatliches Limit
Uzbekistan 1% 1GB 30GB
Oman 1% 1GB 30GB
Qatar 20% 40MB 250MB
VAE 20% 40MB 250MB
Standard, weltweit 20% 50MB 500MB
  • Bei Geräten in Uzbekistan und Oman ist Relay bis zu einem Batteriestand von 1% erlaubt; das tägliche Limit liegt beim 20-Fachen des Standardwerts, das monatliche beim 60-Fachen.
  • Geräte in Qatar und den VAE sind auf niedrigere Limits als den Standardwert beschränkt.
  • Warum die länderspezifischen Stufen so aufgebaut sind, lässt sich nicht sicher feststellen; möglich sind nur Vermutungen.
  • Selbst die weltweite Standardfreigabe erlaubt monatlich 500MB fremden Traffics über den heimischen Internetanschluss des Nutzers.

Testaufbau und Methodik

  • Über 30 Tage wurde auf iOS-Geräten, auf denen eine Partner-App mit erteilter Einwilligung ausgeführt wurde, eine TLS-Intercepting-Proxy-Erfassung durchgeführt; als Beispiel-App diente XYO COIN mit integriertem Bright SDK.
  • Es wurde eine statische Analyse von brdsdk.framework version 1.532.120 für das iOS-arm64-Binary durchgeführt.
  • Bestimmte Hostnamen, Zertifikat-Fingerprints und die TLS-Infrastruktur von Bright Data sind für jeden, der dieselben Anfragen ausführt, öffentlich beobachtbar.
  • Sitzungsspezifische Identifikationsdaten aus der Research-Flotte oder von Research-Clients sind im Dokument nicht enthalten.

Zeitleiste

  • Am 11. Mai 2026 wurde eine E-Mail zur Vorabbenachrichtigung an privacy@brightdata.com gesendet.
  • Bis zum Veröffentlichungszeitpunkt gab es keine Antwort auf diese Benachrichtigung.

Abwehransätze

  • Der Traffic hinterlässt am Netzwerkrand einen klaren Fingerprint, und das SDK ist so aufgebaut, dass es identifizierbare Symbole im App-Binary hinterlässt.
  • Ansatz 1, DNS-Blocking, ist eine einfache und wirksame Methode für Geräte, deren Traffic über das Netzwerk geroutet wird.
    • proxyjs.brdtnet.com
    • proxyjs.luminatinet.com
    • proxyjs.bright-sdk.com
    • clientsdk.bright-sdk.com
    • clientsdk.brdtnet.com
  • Das Blockieren von proxyjs.* unterbricht den Peer-Tunnel und hat keine Auswirkungen auf Kunden, die den Proxy-Service für Bright-Data-Kunden, der auf anderen Domains läuft, rechtmäßig nutzen.
  • Ansatz 2, TLS-SNI-Filtering, blockiert oder warnt bei TLS-Handshakes, deren server_name mit *.brdtnet.com, *.luminatinet.com, *.luminati.io übereinstimmt.
  • SNI-Filtering funktioniert am Netzwerkrand ohne TLS-Inspektion.
  • Ansatz 3, Erkennung über TLS-Zertifikat-Fingerprints, basiert auf Blockierung oder Warnung anhand der folgenden Fingerprints.
    • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
    • .luminatinet.com → SHA256 5028612e625befea…
  • Die Zertifikat-Fingerprints bleiben bis zu einer Zertifikatserneuerung durch Sectigo stabil; das aktuelle Zertifikat ist bis Mitte 2026 gültig.
  • Wegen der Einschränkungen rund um use_netifs funktionieren alle drei Ebenen nur dann, wenn der Traffic den Netzwerkrand passiert.
  • Wenn iOS-Geräte Mobilfunk nutzen, sorgt die use_netifs-Bindung des SDK dafür, dass Peer-Traffic das Unternehmens-WLAN vollständig umgeht.
  • Eine ergänzende Kontrolle für Flotten verwalteter Geräte ist ein MDM-basiertes Scannen von App-Binaries: Dabei wird in installierten Apps nach den Swift-Symbolen BrdWebSocketFacade und BrdNetwork.DNSResolver gesucht, und Apps mit diesen Symbolen werden auf firmeneigenen Geräten verboten.
  • Privathaushalte, die sich wegen bestimmter Smart-TVs oder mobiler Apps sorgen, können die oben genannten Hostnamen in den DNS-Einstellungen des Routers blockieren.
  • Beispiele für Blocking-Tools sind Pi-hole, NextDNS, Cloudflare Gateway oder entsprechende Funktionen des ISP.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare

  • Wenn man schon über dieses Protokoll spricht, könnte man auch einen umgekehrten Honeypot bauen, der bei jeder Anfrage freiwillig zufällig erzeugte Müll-Daten ausliefert; für jemanden mit übrig gebliebenen Tokens wäre das vielleicht ein lustiges Vibe-Coding-Projekt

    • Es scheint nicht einmal nötig zu sein, das Protokoll tatsächlich zu implementieren. Den Logs nach zu urteilen scheitern viele dieser Residential Proxies völlig daran, sich zu verbergen, sodass man ihnen einfach problemlos Müll-Daten ausliefern kann
      Nicht einmal Vibe Colding ist dafür nötig, und es gibt bereits Dutzende Tools, die so etwas können. Viele davon liefern solchen Proxies seit über einem Jahr erfolgreich unendlich viel Müll-Daten

  • Ich verstehe überhaupt nicht, warum man einen Fernseher oder sonst irgendein Haushaltsgerät mit dem Internet verbinden sollte. Es gibt keinen guten Grund dafür

    • Die Leute schauen Streaming-Dienste auf dem Fernseher. Den Fernseher mit dem Internet zu verbinden ist der einfachste Weg, das zu tun