La smart TV du salon est un nœud de l’économie du scraping IA

(blog.includesecurity.com)

3 points par GN⁺ 2026-06-07 | 2 commentaires | Partager sur WhatsApp

Le SDK Bright Data intégré dans des applications grand public transforme, avec le consentement de l’utilisateur, un téléphone ou une smart TV en nœud de sortie de proxy résidentiel, et achemine le trafic de web scraping des clients via des IP domestiques
Les proxies résidentiels sont un moyen de contournement permettant d’atteindre des sites cibles via l’IP de clients résidentiels payants, dans un environnement où Cloudflare, DataDome, HUMAN et d’autres limitent ou bloquent les requêtes provenant d’IP cloud connues
Les TV connectées n’ont pas de contrainte de batterie, restent toujours connectées au Wi‑Fi et fonctionnent 24/7 en veille, ce qui en fait de meilleures conditions de proxy que les téléphones en matière de disponibilité permanente et de capacité à être laissées sans surveillance
Le SDK iOS récupère depuis un endpoint de configuration non authentifié les critères d’inactivité, les limites de bande passante et la liste des partenaires, puis ouvre un tunnel pair à pair WebSocket pour traiter la télémétrie d’état de l’appareil et les tâches de scraping cmd_tun
La défense repose surtout sur le blocage DNS de proxyjs.* et clientsdk.*, le filtrage SNI, la détection d’empreintes de certificats TLS et l’analyse binaire des applications par MDM ; sur iOS, use_netifs limite la visibilité fondée sur les VPN

Vue d’ensemble

Indépendamment de l’opposition communautaire à la construction de datacenters destinés à renforcer les capacités IA, les appareils domestiques peuvent être utilisés comme structure de collecte distribuée de données pour l’entraînement de l’IA
Bright Data vend l’accès à un réseau de proxies résidentiels de plus de 400M d’adresses IP domestiques, utilisées par ses clients pour acheminer du trafic de web scraping ; la source d’approvisionnement est un SDK intégré à des applications grand public
Ce SDK transforme, avec le consentement de l’utilisateur, des téléphones ou des smart TV en nœuds de sortie ; l’analyse porte sur son mode de fonctionnement, les plateformes de déploiement et les raisons pour lesquelles les TV connectées à Internet conviennent aux proxies de web scraping pour modèles d’IA

Pourquoi c’est important maintenant

Les entreprises d’IA dépendent du contenu issu du web scraping pour le préentraînement, la recherche et la recherche augmentée, le grounding des agents et les fonctions de recherche
Le web moderne ne se laisse pas facilement scraper depuis des datacenters, et Cloudflare, DataDome, HUMAN ainsi que d’autres limitent ou bloquent les requêtes en provenance d’IP cloud connues
L’alternative consiste à atteindre les sites cibles depuis les IP de clients résidentiels payants, comme des abonnés Comcast ou T-Mobile, via des proxies résidentiels
Une citation d’un article de Krebs d’octobre 2025 affirme que « l’excès de proxies provenant d’Aisuru et d’autres sources alimente des efforts massifs de collecte de données liés à plusieurs projets d’IA »
Des mesures académiques remontant à 2019 concluent que ces réseaux sont massivement détournés, et le FBI a également publié au début de l’année une alerte officielle
La plupart des reportages existants se concentrent sur l’offre illégale de proxies résidentiels, comme les botnets tels que Aisuru et Kimwolf, les applications trojanisées comme PROXYLIB, ou le matériel IoT préinfecté comme IPIDEA
Le versant de l’offre légale a été relativement peu examiné ; Bright Data, qui se présente dans son marketing comme le plus grand réseau mondial de proxies résidentiels, met en avant « 150M+ IPs » issues d’un SDK avec consentement intégré dans des applications partenaires

Pourquoi les TV connectées sont des proxies idéaux

Élément	Téléphone	Smart TV / CTV
Alimentation	Sur batterie la majeure partie de la journée	Toujours branchée au secteur
Réseau	Wi‑Fi + cellulaire	Toujours en Wi‑Fi, haut débit
Temps de fonctionnement	Intermittent	24/7 en veille
Limites de bande passante	Faibles, contraintes cellulaires	Pratiquement illimitées
Attention de l’utilisateur	Utilisation active	Souvent laissée sans surveillance
Interface de consentement	Texte sur écran de téléphone	Texte à parcourir avec les flèches de la télécommande
Supervision entreprise/famille	Plus élevée, via MDM, EDR mobile, etc.	Pratiquement inexistante

Une TV n’atteint pas 1 % de batterie, ne change pas souvent de réseau Wi‑Fi et ne se verrouille pas pendant que l’utilisateur dort
Certains éditeurs partenaires révèlent leur relation avec Bright Data dans leur politique de confidentialité ; la politique de confidentialité de PlayWorks en est un exemple
Une mention dans la politique de confidentialité n’est pas un point de contrôle adapté au téléviseur : il est difficile de faire défiler des documents juridiques avec les flèches d’une télécommande, et les boîtes de dialogue de consentement intégrées à l’application ne montrent pas clairement que des clients payants de Bright Data font transiter leur trafic de scraping via l’accès Internet domestique de l’utilisateur
L’écran d’opt-in de l’application Roku Petflix, documenté par The Verge, indique : « pour voir moins de publicités et profiter gratuitement, autorisez Bright Data à utiliser occasionnellement les ressources disponibles de votre appareil et son adresse IP pour télécharger des données web publiques sur Internet »
La boîte de dialogue Petflix emploie le terme « occasionnellement », mais la configuration du SDK publiquement consultable contient max_bw_monthly_wifi: 200,000,000,000, soit un budget Wi‑Fi mensuel par défaut de 200 Go

Entités que Bright Data désigne comme partenaires

Bright Data expose un endpoint de manifeste partenaires accessible à tous, sans authentification
Éléments d’identification à forte confiance d’après des sources publiques

Partner ID	Entité	Taille
`playworks_digital`	PlayWorks Digital Ltd	Plus de 400 jeux CTV, portée d’environ 250M de foyers TV via Comcast, Sky, Cox, LG, Samsung, Vizio et Roku
`cloudtv`	CloudTV	Intégré à plus de 125 marques de TV et plus de 15 OEM
`longvision_media_hong_kong_co_limited`	Longvision Media HK (LongTV)	5M d’utilisateurs OTT à Hong Kong et en Malaisie
`viber_media_s_r_l`	Viber Media S.à r.l. (Rakuten)	250M à 820M d’utilisateurs mensuels de la messagerie Viber
`supercent_inc`	Supercent	Éditeur mobile n°1 en Corée du Sud par téléchargements en 2023
`moonfrog_labs_private_limited`	Moonfrog Labs	Environ 10M de MAU pour Teen Patti Gold seul, société acquise pour 90M$
`hola_networks`	Hola Networks	Maison mère historique de Bright Data ; selon l’ancien marketing de Hola, le pic d’utilisateurs allait de plusieurs dizaines de millions à environ 100M+

desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp figurent dans le manifeste, mais il est difficile de les identifier à partir de sources publiques
bright_screensavers, bright_videos, brightdata sont des applications propres à Bright Data
Le fait que ces noms apparaissent dans la configuration de Bright Data suggère qu’une intégration a pu exister à un moment donné, mais ne constitue pas une preuve directe que les applications actuellement distribuées par un éditeur donné embarquent le SDK en production
Ce que la liste des partenaires démontre directement, c’est que Bright Data diffuse cette liste sur un endpoint public sans authentification, et qu’au moins trois acteurs centrés sur la CTV — dont PlayWorks, CloudTV et Longvision — ont monétisé les appareils des utilisateurs comme nœuds de sortie de proxy résidentiel
Selon ses propres supports marketing, PlayWorks revendique une distribution CTV couvrant les principales plateformes TV et les FAI, avec une portée de plusieurs centaines de millions de foyers

Comment le SDK Bright Data transforme les appareils des utilisateurs en nœuds de sortie de proxy résidentiel

Le SDK Bright Data est un produit commercial publiquement documenté, avec une documentation d’intégration SDK pour les éditeurs et une variante JavaScript pour le web
L’analyse s’appuie sur de la rétro-ingénierie d’un framework iOS déployé et sur 30 jours d’instrumentation du trafic à l’exécution
Le SDK est distribué sous la forme du framework iOS brdsdk.framework à l’intérieur des applications partenaires
Configuration sans authentification
- À chaque exécution, le SDK appelle la requête suivante
- GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
- Le point de terminaison fonctionne sans authentification significative, et le serveur ne vérifie que deux paramètres de requête : appid, qui correspond à l’identifiant de bundle de l’app, et ver, qui correspond à la chaîne de version du SDK
- En fournissant l’identifiant de bundle visible dans la fiche App Store d’une application partenaire, une chaîne de version du SDK et un UUID généré arbitrairement, on obtient une configuration identique à celle renvoyée à un véritable appareil
- La réponse contient des feature flags, des seuils de détection d’inactivité comme le niveau de batterie, les plafonds CPU/mémoire et les règles Wi‑Fi/cellulaire, des paliers de bande passante par pays, ainsi qu’une structure contenant le manifeste partenaire
- La configuration inclut des règles d’inactivité permettant à l’appareil d’être éligible au relais de trafic, un flag pour router le trafic pair autour du VPN, une map reliant les installations multi-plateformes à une seule identité, et des limites de bande passante par pays
Tunnel pair
- Après avoir récupéré la configuration, le SDK ouvre un WebSocket persistant vers l’adresse suivante
- wss://proxyjs.brdtnet.com:443
- À la date de rédaction, ce nom d’hôte se résout vers les IP AWS Global Accelerator 3.33.193.183, 15.197.193.114
- Le certificat TLS est CN=*.luminatinet.com, et Luminati Networks était le nom de l’entreprise Bright Data avant 2018
- Même après le rebranding de 2018, l’infrastructure SDK active utilise encore des certificats legacy, et le trafic luminatinet.com ou brdtnet.com n’indique pas un usage de Bright Data côté client, mais constitue un indice d’identification du plan de tunnel pair
- Les services proxy actuels destinés aux clients fonctionnent sur des domaines de marque brightdata.com, donc le trafic réseau vers luminatinet.com et brdtnet.com correspond au plan de tunnel pair
- Le serveur s’identifie comme uWebSockets: 20
- Le point de terminaison pair n’exige pas d’authentification à l’upgrade : après avoir accepté un upgrade WebSocket valide au niveau TLS, il envoie immédiatement une trame de couche applicative qui renvoie l’IP publique du client
- Flux du handshake
- 1. Serveur → Client tunnel_init : crée la session et renvoie l’IP publique du client
- 1. Serveur → Client cid_set : assigne un identifiant de suivi de session au format <IP>-<token>/ls<N>c<M>p443_<IP>_<counter>, confirmé comme correspondant au champ cid observé dans la télémétrie de vrais appareils
- 1. Serveur → Client status_get : interroge l’état d’inactivité de l’appareil, sa batterie, son type de réseau et sa bande passante disponible, et l’appareil répond avec une télémétrie continue comprenant 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. Une fois le handshake terminé, si l’appareil déclare un état favorable, la couche serveur d’appariement des tâches peut pousser des trames cmd_tun, que le SDK exécute sous forme de requêtes HTTP vers des sites tiers avec comme origine l’IP résidentielle de l’utilisateur
- Toutes les trames du WebSocket sont du JSON brut avec une enveloppe fixe
- {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
- Commandes extraites du binaire et confirmées dans les communications réelles
- | Direction | cmd | But |
- |---|---|---|
- | Serveur → Client | tunnel_init | Ouverture de session, écho de l’IP publique |
- | Serveur → Client | cid_set | Attribution de l’identifiant de session |
- | Serveur → Client | status_get | Interrogation de l’inactivité, de la batterie et de la bande passante de l’appareil |
- | Serveur → Client | cmd_tun / tun | Livraison d’une tâche de scraping |
- | Serveur → Client | dns | Demande de résolution DNS cible |
- | Serveur → Client | consent | Demande d’état du consentement |
- | Client → Serveur | status_send | Heartbeat périodique d’état de l’appareil |
- | Client → Serveur | tun_report / tun_ack / tun_fin | Réponses sur le cycle de vie de la tâche de relais |
- | Client → Serveur | tunnel_init_decline | Refus de session |
- | Client → Serveur | logs | Envoi de journaux de diagnostic au serveur |
- Il n’existe ni signature de message, ni HMAC, ni certificat client, ni attestation d’appareil ; dans les faits, seuls la couche TLS et les filtres de réputation IP du serveur distinguent les pairs qui reçoivent de vraies tâches
- Pour les lecteurs familiers des protocoles de malware commerciaux, le niveau de sécurité est en pratique inférieur à celui d’un C2 classique
Ce que le SDK considère comme « inactif »
- La configuration définit les règles d’état de l’appareil autorisant le relais du trafic d’autrui
```
"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
}
```
- En raison des flags ignore_screen_on et ignore_on_call, « inactif » ne signifie pas que l’utilisateur est éloigné de son appareil, mais que CPU, mémoire et batterie restent dans les seuils du SDK
- Un utilisateur en appel ou en train de lire activement l’écran peut donc malgré tout être considéré comme inactif à des fins de relais
Liaison d’identité entre plateformes
- La configuration contient la map dual_pairing suivante
```
"dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
```
- Cette map est une structure de liaison côté serveur qui regroupe comme une seule entité les installations iOS, Windows et macOS d’une même marque
- Le champ http3_enabled: true est un flag pour le transport pair basé sur QUIC, et de futures versions pourraient déplacer le tunnel pair de TCP/443 vers UDP/443
- Les défenses qui détectent le WebSocket par suivi des connexions TCP pourraient ne plus fonctionner en cas de bascule vers UDP/443
Contournement de l’inspection
- Le flag use_netifs: true de la configuration SDK est la condition qui amène le code binaire du SDK à construire NWConnection sur des interfaces requises spécifiques, au lieu du chemin par défaut du système
- Les interfaces requises sont en0 pour le Wi‑Fi ou pdp_ip0 pour le cellulaire
- Sur iOS, cette méthode contourne complètement l’interface tun0 d’un VPN configuré ; même si le reste du trafic HTTPS de l’application passe par le VPN, le tunnel pair, lui, n’emprunte pas le VPN configuré par l’utilisateur
L’environnement de recherche d’interception TLS transparente a capturé tous les appels HTTPS du SDK, mais n’a pas réussi à capturer le tunnel pair proxyjs.brdtnet.com:443, alors même que le port 443 était explicitement redirigé vers l’inspecteur
- Le contournement utilise l’API documentée d’Apple NWParameters.requiredInterface
- Le SDK utilise deux contournements d’inspection indépendants
- Plan de contrôle : la récupération de configuration et les pings de télémétrie reposent sur les primitives CFHTTPMessage de CFNetwork plutôt que sur URLSession et NSURLConnection, neutralisant ainsi l’instrumentation au niveau de URLSession, le swizzling, les network extensions et les sous-classes URLProtocol, courants dans les outils de sécurité pour applications mobiles, tout en respectant le proxy système, ce qui maintient une visibilité pour les chercheurs travaillant sur l’interception TLS
- Plan de données : le tunnel pair repose sur NWConnection avec l’interface physique définie comme interface requise, neutralisant le VPN et garantissant que le scraping s’exécute depuis une IP résidentielle
- Pour les équipes sécurité qui utilisent le MDM, l’inspection du trafic via VPN d’entreprise ou le contrôle parental du routeur domestique, le canal le plus sensible est conçu pour contourner la couche de visibilité

Paliers par pays

Les paramètres incluent des seuils de bande passante par pays

Pays	Batterie minimale pour le relais	Limite quotidienne	Limite mensuelle
Uzbekistan	1%	1GB	30GB
Oman	1%	1GB	30GB
Qatar	20%	40MB	250MB
UAE	20%	40MB	250MB
default, worldwide	20%	50MB	500MB

Sur les appareils en Uzbekistan et à Oman, le relais est autorisé jusqu’à 1% de batterie, avec une limite quotidienne 20 fois supérieure à la valeur par défaut et une limite mensuelle 60 fois supérieure
Les appareils au Qatar et aux UAE sont limités à des quotas inférieurs à la valeur par défaut
Il est impossible de déterminer avec certitude pourquoi ces paliers par pays sont configurés ainsi ; on ne peut que spéculer
Même l’allocation par défaut au niveau mondial autorise 500MB par mois du trafic d’autres personnes via la connexion Internet domestique de l’utilisateur

Configuration de test et méthodologie

Une capture via proxy d’interception TLS a été réalisée pendant 30 jours sur un appareil iOS exécutant une app partenaire installée avec consentement ; l’app d’exemple inclut XYO COIN, qui embarque Bright SDK
Analyse statique effectuée sur brdsdk.framework version 1.532.120, binaire iOS arm64
Les noms d’hôte spécifiques de Bright Data, les empreintes de certificats et l’infrastructure TLS sont observables publiquement par quiconque effectue les mêmes requêtes
Le document ne contient aucune donnée d’identification par session concernant un parc de recherche ou des clients de recherche

Chronologie

11 mai 2026 : envoi d’un e-mail de notification préalable à publication à privacy@brightdata.com
Au moment de la publication, aucune réponse à cette notification

Approches de défense

Le trafic laisse une empreinte claire à la frontière du réseau, et le SDK est conçu pour laisser des symboles identifiables dans le binaire de l’app
Approche 1 : le blocage DNS est une méthode simple et efficace pour les appareils routant leur trafic via le réseau
- proxyjs.brdtnet.com
- proxyjs.luminatinet.com
- proxyjs.bright-sdk.com
- clientsdk.bright-sdk.com
- clientsdk.brdtnet.com
Le blocage de proxyjs.* interrompt les tunnels pair à pair, sans impact pour les clients qui utilisent légitimement les services proxy de Bright Data destinés aux clients fonctionnant sur d’autres domaines
Approche 2 : le filtrage TLS SNI consiste à bloquer ou signaler les handshakes TLS dont le server_name correspond à *.brdtnet.com, *.luminatinet.com, *.luminati.io
Le filtrage SNI fonctionne à la frontière du réseau sans inspection TLS
Approche 3 : la détection par empreinte de certificat TLS permet de bloquer ou signaler selon les empreintes suivantes
- .brdtnet.com → SHA256 313ce4ec7d5a51e5…
- .luminatinet.com → SHA256 5028612e625befea…
Les empreintes de certificats restent stables jusqu’au remplacement des certificats Sectigo, et les certificats actuels sont valides jusqu’à mi-2026
En raison des contraintes liées à use_netifs, les trois couches ne fonctionnent que lorsque le trafic traverse la frontière du réseau
Quand un appareil iOS utilise le cellulaire, la liaison use_netifs du SDK crée une condition dans laquelle le trafic pair à pair contourne entièrement le Wi-Fi d’entreprise
Un contrôle compensatoire pour un parc d’appareils gérés consiste à effectuer, via MDM, un scan des binaires d’apps afin de rechercher les symboles Swift BrdWebSocketFacade et BrdNetwork.DNSResolver, puis d’interdire sur les appareils fournis par l’entreprise les apps contenant ces symboles
Les particuliers inquiets d’une smart TV ou d’une app mobile spécifique peuvent bloquer les noms d’hôte ci-dessus dans les paramètres DNS de leur routeur
Exemples d’outils de blocage : Pi-hole, NextDNS, Cloudflare Gateway, ou la fonctionnalité équivalente de leur FAI

2 commentaires

GN⁺ 2026-06-08

Commentaires sur Hacker News

Après avoir récupéré la configuration, le SDK ouvre un WebSocket permanent vers wss://proxyjs.brdtnet.com:443, et ce nom d’hôte se résout vers une IP d’AWS Global Accelerator
Il y a une certaine ironie à voir le scraper et les sites scrapés être probablement tous deux hébergés sur AWS, tout en jouant à un sophistiqué jeu du chat et de la souris en prétendant ne pas l’être
- Cloudflare vend même des services de protection DDoS à des tableaux de bord de contrôle DDoS
- Bright Data est aussi proposé comme produit sur AWS Marketplace
  https://aws.amazon.com/marketplace/seller-profile?id=bf9b432...
- Ajout immédiat à la liste de blocage DNS
- C’est similaire à la manière dont le gouvernement américain a besoin d’entreprises commerciales qu’il ne régule pas correctement, puis les laisse fournir des atteintes à la vie privée comme s’il s’agissait de moyens légitimes, ce qui lui permet ensuite de se laver les mains de tout ça
Je ne connecte aucun appareil intelligent au Wi‑Fi. S’il ne fonctionne pas sans connexion, je n’en veux pas
Pour moi, une TV ne sert que d’écran, et tant qu’elle a une entrée HDMI, ça me suffit
- J’ai une smart TV qui n’a jamais communiqué avec Internet depuis sa sortie d’usine, mais ça ressemble à un équilibre assez précaire
  J’ai peur qu’un invité voie le toast « Services unavailable, press [menu] to troubleshoot » qui s’affiche quelques secondes au-dessus de l’image HDMI, puis la connecte en voulant aider. Là, elle recevrait d’un coup 4 ou 5 ans de mises à jour firmware, transmettrait les données de visionnage accumulées pendant un demi‑décennie et extraites tant bien que mal du flux HDMI en prévision de cet instant, et des pubs surgiraient de partout
  Même si ça n’arrive pas tout de suite, j’ai l’impression qu’il y a quelque part au fond de l’OS un drapeau du genre makeEverythingWorse, prêt à s’activer dans la femtoseconde où The Beast flairera un numéro de patch un peu plus élevé. Au final, elle ne servirait plus qu’à informer quelqu’un chez Samsung que l’émission que j’aime est sur HDMI2, puis finirait en état dégradé
  J’ai déjà empêché la TV de ma mère de reculer au bord de ce précipice, donc cette inquiétude me paraît fondée. L’écran d’accueil vide de la TV et l’icône d’antenne barrée semblent murmurer « nous aussi on a Disney+ et CraveTV… appuyez sur [menu]… ne faites pas attention à la note que votre fils a collée sur la table basse »
- Pas grave. Avec des technologies comme Amazon Sidewalk et des modules 4G/5G bon marché et légers, plus personne n’a besoin de demander l’autorisation pour se connecter
  On peut toujours utiliser de vieux appareils, mais vous ne voulez pas être largué, si ? Si vous n’acceptez pas simplement ce joug numérique, les gens autour de vous penseront peut-être que vous êtes pauvre ou un C.H.U.D.
- Je comprends ce principe en théorie, mais je ne vois pas très bien comment ça fonctionne concrètement dans la vie moderne, quand on veut regarder Netflix ou YouTube sur sa TV
  Ça peut être une TV ou une box Android, mais au bout du compte on finit forcément par faire confiance à un logiciel d’un tiers — et aux apps d’autres tiers qu’il peut exécuter. L’alternative, c’est un serveur Jellyfin local, mais pour y mettre les contenus que la famille veut voir, il y a de très fortes chances qu’il faille enfreindre la loi
  Personnellement, je préférerais ne pas avoir de TV du tout à la maison, mais ce n’est pas facile de convaincre la famille ;-)
- Ma TV TCL exige d’être connectée d’abord pour pouvoir lire les règles Google que je suis censé accepter. Si je ne la connecte pas, c’est comme si j’acceptais une politique que je n’ai pas lue
  Heureusement, sans connectivité, l’étendue concrète des dégâts reste quasiment nulle
- Ce qui est frustrant, c’est que je veux bien certaines fonctions qu’on obtient seulement en connectant la TV au réseau. En particulier, la possibilité de piloter via l’API exposée par la TV des choses comme l’allumage ou le choix de l’entrée
  On peut gérer ça en la plaçant sur un VLAN sans accès à Internet externe, mais le simple fait d’avoir à en arriver là est vraiment pénible
En principe, bloquer la TV sur le réseau local est une bonne idée. Mais les appareils Amazon Fire n’ont-ils pas, pendant un temps, utilisé Sidewalk pour créer une route de retour vers la maison mère ?
Il aurait suffi que la sonnette Ring du voisin soit restée dans sa configuration par défaut
La configuration du SDK contient un drapeau use_netifs: true, qui fait que, dans le binaire du SDK, la création d’une NWConnection cible non pas la route système par défaut, mais une interface requise spécifique, en0 (Wi‑Fi) ou pdp_ip0 (cellulaire)
Sur iOS, cela contourne complètement l’interface tun0 du VPN configuré. Même si le reste du trafic HTTPS de l’app passe par le VPN, le tunnel pair-à-pair, lui, ne passe pas par le VPN configuré par l’utilisateur
Quel serait un cas d’usage légitime pour cette API ? Dans quel cas, et pourquoi, devrait-on permettre à une app de contourner le VPN configuré par l’utilisateur ?
- Un cas d’usage légitime serait que l’app soit une application fournissant un VPN, ou qu’elle soit conçue pour communiquer avec quelque chose sur un réseau local proche plutôt qu’avec une cible joignable à l’échelle mondiale
- Quand le tunneling complet ne fonctionne temporairement pas, le split tunneling peut permettre de contourner des problèmes causés par le VPN
  Mais à mon avis, une app ne devrait pas pouvoir contourner des choses comme les frontières réseau
Question naïve : si je veux apprendre à détecter ce genre de choses sur mes appareils — surtout iOS — ou sur mon réseau domestique, quels mots-clés devrais-je chercher ?
J’aimerais repérer les apps où ce SDK est actif sur mes appareils et les supprimer
- Il existe peut-être de meilleures ressources, mais si vous avez aussi un Mac, cet article avait l’air correct au premier abord
  https://www.thequantizer.com/tutorials/wireshark-iphone-traf...
  Cela fait un moment que je n’ai pas fait ce genre de traçage moi-même, mais Wireshark était très facile à utiliser, et une fois le réseau exposé il existe aussi beaucoup de références en ligne
  Le fait que ça contourne le VPN était particulièrement horrible, et l’ensemble me paraît assez affreux. Personnellement, j’aimerais qu’il y ait une limite à la quantité de texte qu’on peut mettre dans des conditions d’utilisation. Plus personne n’a envie de lire autant de texte aujourd’hui.
Les mesures d’atténuation proposées semblent faibles
Le blocage DNS et le filtrage SNI semblent susceptibles de pousser Bright Data à faire tourner ses endpoints si le sujet attire suffisamment l’attention. Il faudra du temps pour que toutes les apps, y compris le SDK, rattrapent le mouvement, mais s’ils sont malins, le SDK a peut-être déjà une connexion de commande et contrôle de secours à tenter quand il ne peut pas accéder longtemps à l’endpoint actuel
Les empreintes TLS sont probablement la chose la moins coûteuse à modifier en permanence, sauf si le SDK les fige
Les solutions MDM sont presque inaccessibles aux particuliers, et on ne sait pas non plus à quel point le nom du SDK est stable au point de pouvoir s’y fier
Cela ne veut pas dire qu’il existe une meilleure approche. Ce genre de comportement devrait sans doute être explicitement interdit par Apple et Google, avec résiliation immédiate des comptes éditeur
Mon pare-feu ne devrait pas bloquer l’accès au monde extérieur. En revanche, ce qui est contrôlé par Home Assistant devrait être autorisé
- Beaucoup de smart TV intègrent de la publicité. J’ai acheté une Sony Bravia d’occasion et je l’ai laissée sur le trottoir au bout de trois jours tellement elle m’agaçait
  Elle était coincée dans une boucle de démarrage et l’interface avait environ 3 secondes de latence à l’entrée. Je ne l’avais même jamais connectée au réseau, et elle a quand même eu la gentillesse d’afficher des pubs pour des films de studio Sony sortis à l’époque de la fabrication du téléviseur, il y a environ 10 ans
Je viens de vérifier et j’utilise AdGuard sur tout le réseau. Sur la TV, 80 % des requêtes sont bloquées, et sur l’ensemble du réseau, environ 50 % le sont. C’est délirant
Si ce type de proxy n’est pas illégal, il devrait au moins l’être. Dire que cela frôle le contournement des hypothèses de base sur le routage Internet ainsi que sur la location et la propriété des adresses IP reste encore faible par rapport à la manière dont Bright Data en a fait un produit monétisable
On trouve cette formule : « Vous autorisez Bright Data à utiliser occasionnellement les ressources inutilisées de votre appareil et votre adresse IP pour télécharger des données web publiques depuis Internet »
Ce qui induit l’utilisateur final en erreur, c’est l’expression « télécharger des données web publiques ». Si ces données sont publiques, pourquoi Bright Data ne peut-il pas les télécharger directement ? Probablement parce que la partie en face ne le souhaite pas. Ce produit revient à faire aider l’utilisateur, pour le compte de quelqu’un qui a de l’argent mais se trouve dans une position défavorable sur Internet pour des raisons légitimes, à permettre à Bright Data de contourner une propriété non désirée du fournisseur de données « publiques »
C’est absolument lamentable, mais comme je savais que ça allait dans cette direction, je ne suis honnêtement ni très surpris ni très inquiet. Les gens votent avec leur portefeuille depuis longtemps. Les personnes utilisées ici comme proxys ne sont pas Joe le Hacker soucieux de sa vie privée, mais nos parents et des millions d’autres gens qui veulent juste se divertir à la fin de la journée, ainsi que des parents avec de jeunes enfants
Chaque jour, la théorie de l’Internet sombre me paraît plus plausible, et honnêtement je pense que ça me conviendrait. Internet va s’effondrer en un interréseau féodal où, quel que soit le routage, il faudra une clé à chaque saut, et c’est probablement ce qu’il faut pour que de vraies personnes — et, honnêtement, aussi des agents — puissent préserver un minimum de la confiance qui est activement contournée aujourd’hui
- C’est totalement légal, et il n’existe pas de loi sur le routage IP et la propriété des adresses comme vous le dites
L’un des problèmes visibles ici est le même que lorsqu’on exploite un nœud de sortie Tor. Des utilisateurs malveillants peuvent s’en servir pour masquer leur position
Il suffit d’imaginer que le véritable coupable soit quelqu’un qui utilise votre TV comme proxy pour échanger des contenus pédocriminels, et que la police vienne chez vous en estimant que c’est vous qui les diffusez
- Je déteste vraiment la manière dont tout devient hostile à l’utilisateur. Il faut devenir expert en presque tout et suivre l’actualité en permanence, juste au cas où un changement majeur viendrait renverser les hypothèses établies
  Et si malgré tout on le rate et qu’on se plaint, des défenseurs déboulent aussitôt pour justifier, détourner le sujet ou noyer la conversation
  La seule bonne nouvelle, c’est que cette fatigue commence aussi à atteindre les gens ordinaires. Un collègue s’est plaint qu’il devait devenir un administrateur Wi-Fi/Internet à part entière juste pour appliquer correctement des restrictions et des limites à ses enfants
  Je dis ça surtout par frustration. Je ne sais toujours pas très bien quelle serait la bonne solution ici
- Des groupes comme Bright Data ont des procédures de vérification client assez solides. Après une bonne frayeur avec une visite de la police, le véritable auteur finira en prison

GN⁺ 2026-06-07

Avis sur Lobste.rs

En parlant de ce protocole, créer un honeypot inversé qui renverrait volontairement des données aléatoires et inutiles à chaque requête pourrait faire un projet de vibe coding amusant pour quelqu’un qui a des tokens en trop
- Il ne semble même pas nécessaire d’implémenter le protocole. D’après les logs, une bonne partie de ces proxys résidentiels échouent complètement à se dissimuler, donc on peut simplement leur envoyer facilement des données poubelles
  Pas besoin non plus de vibe coding, il existe déjà des dizaines d’outils capables de faire ça. Beaucoup d’entre eux fournissent déjà sans fin des données poubelles à ce type de proxy depuis plus d’un an
Je ne comprends absolument pas pourquoi on connecte une TV, ou n’importe quel autre appareil électroménager, à Internet. Il n’y a aucune bonne raison de le faire
- Les gens regardent des services de streaming sur leur TV. Connecter la TV à Internet est la manière la plus simple de le faire

La smart TV du salon est un nœud de l’économie du scraping IA

Vue d’ensemble

Pourquoi c’est important maintenant

Pourquoi les TV connectées sont des proxies idéaux

Entités que Bright Data désigne comme partenaires

Comment le SDK Bright Data transforme les appareils des utilisateurs en nœuds de sortie de proxy résidentiel

Configuration sans authentification

Tunnel pair

Ce que le SDK considère comme « inactif »

Liaison d’identité entre plateformes

Contournement de l’inspection

Paliers par pays

Configuration de test et méthodologie

Chronologie

Approches de défense

À lire aussi

2 commentaires

Commentaires sur Hacker News

Avis sur Lobste.rs