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

(blog.includesecurity.com)

3 Punkte von GN⁺ 2026-06-07 | 2 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

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
- 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
```
"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.

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.

2 Kommentare

GN⁺ 2026-06-08

Hacker-News-Kommentare

Nachdem die Konfiguration abgerufen wurde, öffnet das SDK eine dauerhafte WebSocket-Verbindung zu wss://proxyjs.brdtnet.com:443, und dieser Hostname wird zu einer AWS-Global-Accelerator-IP aufgelöst
Es hat eine gewisse Ironie, dass sowohl der Scraper als auch die gescrapte Website wahrscheinlich auf AWS gehostet werden und dabei so tun, als hätten sie nichts miteinander zu tun, während sie ein ausgefeiltes Katz-und-Maus-Spiel spielen
- Cloudflare verkauft sogar DDoS-Schutz an DDoS-Control-Panels
- Bright Data ist auch als Produkt im AWS Marketplace gelistet
  https://aws.amazon.com/marketplace/seller-profile?id=bf9b432...
- Direkt zur DNS-Sperrliste hinzugefügt
- Das ähnelt der Struktur, bei der die US-Regierung kommerzielle Unternehmen braucht, die sie nicht ordentlich reguliert, und diese Unternehmen Eingriffe in die Privatsphäre als eine Art legales Mittel anbieten, sodass der Staat sich die Hände in Unschuld waschen kann
Ich verbinde keinerlei Smart-Geräte mit dem WLAN. Wenn etwas ohne Verbindung nicht funktioniert, will ich es nicht
Beim Fernseher reicht es, wenn er einfach nur als Anzeigegerät dient und HDMI-Eingänge hat
- Ich habe einen Smart-TV, der seit dem Auspacken nie mit dem Internet verbunden war, aber das fühlt sich wie ein ziemlich instabiles Gleichgewicht an
  Ich habe Sorge, dass ein Gast den Toast-Hinweis „Services unavailable, press [menu] to troubleshoot“, der ein paar Sekunden über dem HDMI-Bild eingeblendet wird, sieht und in Hilfsbereitschaft doch verbindet. Dann kämen auf einen Schlag 4–5 Jahre Firmware-Updates herein, und die über ein halbes Jahrzehnt aus dem HDMI-Feed irgendwie extrahierten und gespeicherten Sehgewohnheitsdaten würden genau für diesen Moment übertragen, während überall Werbung auftaucht
  Selbst wenn das nicht sofort passiert, wirkt es so, als gäbe es tief im OS ein Flag wie makeEverythingWorse, das in der Femtosekunde aktiviert wird, in der The Beast eine etwas höhere Patch-Nummer wittert. Am Ende bleibt nur ein kaputter Zustand zurück, der allein dem Zweck dient, irgendwem bei Samsung mitzuteilen, dass meine Lieblingssendung HDMI2 ist
  Ich musste auch beim Fernseher meiner Mutter schon einmal verhindern, dass sie diesen Abgrund überschreitet, also halte ich die Sorge für berechtigt. Der leere TV-Startbildschirm mit dem Symbol eines durchgestrichenen Funkmasts lockt praktisch mit „Wir haben auch Disney+ und CraveTV … drücken Sie [menu] … ignorieren Sie den Zettel Ihres Sohns auf dem Couchtisch“
- Kein Problem. Mit Technologien wie Amazon Sidewalk und billigen, kleinen 4G-/5G-Modulen muss heute niemand mehr um Erlaubnis für eine Verbindung bitten
  Man könnte natürlich alte Geräte verwenden, aber man will ja nicht zurückbleiben. Wenn man das digitale Joch nicht einfach akzeptiert, werden die Leute um einen herum sonst noch denken, man sei arm oder ein C.H.U.D.
- Ich verstehe dieses Prinzip theoretisch, bin mir aber nicht sicher, wie das praktisch im modernen Alltag funktionieren soll, wenn man auf dem Fernseher Dinge wie Netflix oder YouTube sehen will
  Es mag ein Fernseher sein oder eine Android-Box, aber letztlich vertraut man irgendwo immer Software von Dritten und darauf, dass darauf wiederum Apps anderer Dritter laufen können. Die Alternative wäre ein lokaler Jellyfin-Server, aber um die Inhalte bereitzustellen, die die Familie sehen will, müsste man mit sehr hoher Wahrscheinlichkeit gegen das Gesetz verstoßen
  Persönlich wäre mir am liebsten, überhaupt keinen Fernseher im Haus zu haben, aber die Familie davon zu überzeugen, ist nicht leicht ;-)
- Mein TCL-Fernseher verlangt, dass ich mich zuerst verbinde, um die Google-Richtlinien lesen zu können, denen ich zustimmen soll. Ohne Verbindung stimmt man also Richtlinien zu, die man gar nicht gelesen hat
  Zum Glück ist der tatsächliche Schadensradius ohne Konnektivität praktisch null
- Frustrierenderweise will ich einige Funktionen, die man nur bekommt, wenn der Fernseher im Netzwerk ist. Vor allem die Möglichkeit, Dinge wie Einschalten oder Eingangswahl über eine vom Fernseher bereitgestellte API zu steuern
  Wenn man ihn in ein VLAN ohne externen Internetzugang steckt, ist das handhabbar, aber allein die Tatsache, dass man so weit gehen muss, ist wirklich lästig
Grundsätzlich ist es gut, den Fernseher im lokalen Netzwerk zu blockieren. Aber hat ein Amazon-Fire-Gerät nicht eine Zeit lang Sidewalk genutzt, um einen Weg zurück zur Zentrale zu schaffen?
Es hätte schon gereicht, wenn die Ring-Türklingel des Nachbarn einfach auf den Standardeinstellungen geblieben wäre
In der SDK-Konfiguration gibt es das Flag use_netifs: true, und dieses Flag sorgt im SDK-Binary dafür, dass beim Erstellen einer NWConnection nicht der Standardpfad des Systems verwendet wird, sondern eine bestimmte erforderliche Schnittstelle wie en0 (WLAN) oder pdp_ip0 (Mobilfunk)
Unter iOS wird dadurch die konfigurierte tun0-Schnittstelle eines VPN vollständig umgangen. Selbst wenn der übrige HTTPS-Traffic der App durch das VPN läuft, geht der Peer-Tunnel nicht durch das vom Nutzer konfigurierte VPN
Was wäre ein legitimer Anwendungsfall für diese API? Wann und warum sollte es einer App erlaubt sein, das vom Nutzer eingerichtete VPN zu umgehen?
- Ein legitimer Anwendungsfall wäre, wenn die App eine VPN-Anwendung bereitstellt oder wenn sie dafür gedacht ist, mit etwas in einem lokalen oder nahegelegenen Netzwerk zu kommunizieren statt mit einem weltweit erreichbaren Ziel
- Wenn vollständiges Tunneling vorübergehend nicht funktioniert, kann man mit Split-Tunneling Probleme umgehen, die durch das VPN selbst entstehen
  Aber ich finde nicht, dass Apps so etwas wie Netzwerkgrenzen umgehen dürfen sollten
Vielleicht eine naive Frage, aber wonach müsste ich suchen, wenn ich lernen will, wie man so etwas auf meinen Geräten — überwiegend iOS — oder im Heimnetz erkennt?
Ich würde gern Apps finden und entfernen, in denen dieses SDK auf meinen Geräten aktiv ist
- Vielleicht gibt es bessere Quellen, aber wenn du auch einen Mac hast, sah dieser Artikel auf den ersten Blick ganz brauchbar aus
  https://www.thequantizer.com/tutorials/wireshark-iphone-traf...
  Ich habe solche Analysen zwar schon länger nicht mehr gemacht, aber Wireshark war meiner Erfahrung nach sehr einfach zu benutzen, und sobald das Netzwerk sichtbar ist, findet man online jede Menge Referenzmaterial
  Besonders schrecklich fand ich, dass es das VPN umgeht, wobei eigentlich das Ganze schlimm ist. Ich persönlich wünschte, es gäbe eine Begrenzung dafür, wie viel in Nutzungsbedingungen stehen darf. Niemand will heutzutage noch so viel Text lesen
Die vorgeschlagenen Gegenmaßnahmen wirken schwach
DNS-Blockierung und SNI-Filterung dürften nur dazu führen, dass Bright Data seine Endpunkte rotiert, sobald dieses Thema genug Aufmerksamkeit bekommt. Es wird zwar dauern, bis alle Apps mit eingebettetem SDK nachziehen, aber wenn sie clever sind, hat das SDK möglicherweise bereits eine Backup-Command-and-Control-Verbindung, die es ausprobiert, wenn es längere Zeit keinen Zugriff auf den aktuellen Endpunkt hat
TLS-Fingerprints zu ändern ist weiterhin die billigste Methode, solange das SDK sie nicht fest verdrahtet
MDM-Lösungen sind für Privatnutzer nahezu unzugänglich, und es ist unklar, wie stabil der Name des SDKs ist, sodass man sich darauf verlassen könnte
Das heißt nicht, dass es einen besseren Ansatz gibt. So ein Verhalten sollte von Apple und Google ausdrücklich verboten werden, und Publisher-Konten sollten sofort gekündigt werden
Meine Firewall sollte den Zugriff auf die Außenwelt nicht blockieren. Was aber von Home Assistant gesteuert wird, sollte erlaubt sein
- Viele Smart-TVs haben Werbung eingebaut. Ich habe einen gebrauchten Sony Bravia gekauft und ihn nach drei nervigen Tagen an die Straße gestellt
  weil er in einer Bootschleife hing und die UI-Eingabeverzögerung etwa 3 Sekunden betrug. Ich hatte ihn nie mit dem Netzwerk verbunden, und trotzdem zeigte er netterweise Werbung für Sony-Studiofilme, die ungefähr vor 10 Jahren beim Herstellungszeitpunkt des Fernsehers aktuell waren
Ich habe gerade nachgesehen: Ich nutze AdGuard für mein gesamtes Netzwerk. Auf dem Fernseher werden 80 % der Anfragen blockiert, und im gesamten Netzwerk etwa 50 %. Komplett verrückt
Wenn diese Art von Proxy nicht illegal ist, dann sollte sie es zumindest sein. Selbst zu sagen, dass sie an der Grenze dazu operiert, grundlegende Annahmen über Internet-Routing sowie die Vermietung und Eigentümerschaft von IP-Adressen zu umgehen, ist noch eine schwache Formulierung im Vergleich dazu, was Bright Data als bezahlbares Produkt verpackt hat
Da steht: „Sie erlauben Bright Data gelegentlich, freie Ressourcen und Ihre IP-Adresse zu verwenden, um öffentliche Webdaten aus dem Internet herunterzuladen“
Der irreführende Teil für Endnutzer ist die Formulierung „öffentliche Webdaten herunterladen“. Wenn die Daten öffentlich sind, warum kann Bright Data sie dann nicht selbst herunterladen? Vermutlich, weil die Gegenseite das nicht will. Dieses Produkt bringt Nutzer dazu, Bright Data dabei zu helfen, unerwünschte Einschränkungen eines Anbieters „öffentlicher“ Daten zu umgehen — stellvertretend für jemanden, der Geld hat, aber im Internet aus legitimen Gründen in einer nachteiligen Position ist
Es ist absolut beklagenswert, aber ehrlich gesagt überrascht es mich nicht einmal und beunruhigt mich auch nicht besonders, weil ich wusste, dass es in diese Richtung geht. Die Leute stimmen schon lange mit ihrem Geldbeutel ab. Als Proxy benutzt werden hier nicht datenschutzbewusste Joe-the-Hacker-Typen, sondern unsere Eltern und Millionen andere Menschen, die nach einem Arbeitstag einfach Unterhaltung wollen, sowie Eltern mit kleinen Kindern
Mit jedem Tag wirkt die Dark Forest Theory plausibler, und ehrlich gesagt fände ich es okay, wenn es in diese Richtung geht. Das Internet wird zu einem feudalen Internetwork zerfallen, in dem für jedes Routing und jeden Hop ein Schlüssel nötig ist, und so lässt sich zumindest ein gewisses Maß an Vertrauen bewahren, das für echte Menschen — und ehrlich gesagt auch für Agenten — gerade aktiv untergraben wird
- Das ist völlig legal, und ein Gesetz zu IP-Routing und Eigentum an Adressen, wie du es beschrieben hast, existiert nicht
Eines der Probleme hier ist dasselbe wie beim Betrieb eines Tor-Exit-Nodes. Böswillige Akteure können ihn nutzen, um ihren Standort zu verbergen
Man muss sich nur vorstellen, dass der eigentliche Täter Kinderpornografie über den Proxy deines Fernsehers verbreitet und dann die Polizei vor deiner Tür steht, weil sie denkt, du würdest das Material verbreiten
- Ich hasse es wirklich, dass alles gegenüber dem Nutzer immer feindseliger wird. Man muss zu fast allem ein Experte werden und ständig die Nachrichten verfolgen, nur für den Fall, dass wieder irgendeine grundlegende Annahme über den Haufen geworfen wird
  Und wenn man es irgendwie verpasst und sich dann beschwert, kommen die Verteidiger in Scharen und rechtfertigen es, lenken vom Punkt ab oder verwässern die Diskussion
  Die immerhin gute Nachricht ist, dass diese Erschöpfung offenbar auch normale Leute erreicht. Ein Kollege hat sich darüber beschwert, dass er praktisch ein vollwertiger Wi-Fi-/Internet-Administrator werden muss, um Beschränkungen und Limits für seine Kinder ordentlich durchzusetzen
  Ich sage das einfach aus Frust. Ich weiß noch nicht wirklich, was hier die richtige Lösung ist
- Gruppen wie Bright Data haben ziemlich gute Know-Your-Customer-Verfahren. Nach einem ordentlichen Schreck durch den Polizeibesuch landet der eigentliche Täter dann im Gefängnis

GN⁺ 2026-06-07

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

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

Überblick

Warum das jetzt wichtig ist

Warum vernetzte Fernseher ideale Proxys sind

Von Bright Data als Partner benannte Ziele

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

Konfiguration ohne Authentifizierung

Peer-Tunnel

Bedingungen, unter denen das SDK „idle“ annimmt

Plattformübergreifende Identitätsverknüpfung

Umgehung von Inspektion

Länderspezifische Stufen

Testaufbau und Methodik

Zeitleiste

Abwehransätze

Verwandte Beiträge

2 Kommentare

Hacker-News-Kommentare

Lobste.rs-Kommentare