Un chercheur indépendant a effectué une rétro-ingénierie du SDK iOS utilisé par **Bright Data**, une entreprise de données de premier plan qui commercialise activement auprès de l'industrie de l'IA. Les conclusions détaillent comment ce SDK, intégré dans diverses applications grand public, convertit les appareils des utilisateurs, y compris les téléviseurs intelligents, en nœuds de sortie de proxys résidentiels. **Bright Data**, le successeur de **Luminati**, se targue de posséder l'un des plus grands réseaux de proxys résidentiels au monde, revendiquant plus de 400 millions d'adresses IP. Une part importante de cette offre provient de ce SDK, auquel les utilisateurs consentent soi-disant via des écrans de consentement dans les applications gratuites, contribuant à un pool de plus de 150 millions d'IP. ### L'impact caché sur votre réseau domestique Publiées le 5 juin par **Include Security** et le chercheur indépendant **Buchodi**, les conclusions soulignent une préoccupation critique : le trafic de web scraping provient de l'adresse IP du domicile de l'utilisateur, et non de celle du client. Bien qu'il ne s'agisse pas d'un risque immédiat de compromission de compte ou de vol de données, l'implication principale est l'utilisation non autorisée de la connexion Internet et de la bande passante d'un utilisateur comme infrastructure pour des opérations de scraping tierces. Les téléviseurs intelligents connectés sont des cibles particulièrement attrayantes pour ce modèle. Ils sont généralement toujours branchés, souvent sur des connexions rapides et effectivement illimitées, et fonctionnent largement sans surveillance, ce qui en fait des relais idéaux pour le trafic de données continu. Les preuves techniques les plus approfondies proviennent de l'analyse du SDK iOS, bien que le support de la plateforme de **Bright Data** et la liste de partenaires publics suggèrent une intégration plus large avec les téléviseurs intelligents. La recherche a également révélé que le canal peer facilitant les tâches de scraping manque d'une authentification robuste, et sur iOS, son trafic peut contourner un VPN configuré. ### À l'intérieur du tunnel peer Lors du lancement d'une application, le SDK établit un contact avec l'un des serveurs de **Bright Data**, qui délivre des instructions sans authentification significative. À partir de là, le serveur peut diriger l'appareil pour récupérer des pages Web en utilisant la connexion Internet de l'utilisateur. Le chercheur a caractérisé les contrôles de sécurité de ce canal de transmission de tâches comme étant plus faibles que ceux généralement trouvés dans la plupart des malwares. Sur les iPhones, le trafic a été observé contournant les VPN, et une grande partie de l'activité du SDK est restée cachée aux outils de surveillance d'applications standard. L'appareil peut continuer à relayer le trafic en arrière-plan, même pendant son utilisation, tant que le niveau de la batterie n'est pas critique. ### Le fossé du consentement Crucialement, les écrans d'opt-in présentés aux utilisateurs déforment souvent l'étendue réelle des opérations du SDK. Par exemple, dans une application Roku nommée **Petflix**, l'écran de consentement indiquait vaguement qu'il utiliserait l'appareil et la connexion "occasionnellement". Cependant, les paramètres internes du SDK autorisent jusqu'à 200 Go de trafic par mois. Dans certains pays, comme l'Ouzbékistan et Oman, ces limites sont définies de manière significativement plus élevée, les appareils étant autorisés à fonctionner presque jusqu'à épuisement de leur batterie. Le SDK peut également lier le téléphone d'un utilisateur et les ordinateurs exécutant les applications de la même société, les traitant comme une seule entité. **Bright Data** liste publiquement ses partenaires d'applications, qui comprennent des développeurs d'applications pour téléviseurs intelligents comme **PlayWorks Digital**, **CloudTV** et **Longvision**. Le chercheur avertit que l'inclusion sur cette liste n'indique qu'une collaboration passée, et non nécessairement qu'une application contient actuellement le SDK ; chacune nécessiterait une vérification individuelle. ### Un vieux modèle, alimenté par la demande d'IA Ce modèle de proxy n'est pas entièrement nouveau. Le prédécesseur de **Bright Data**, **Luminati**, est issu de **Hola VPN**, qui a été [découvert en 2015](https://thehackernews.com/2015/05/hola-widely-popular-free-vpn-service.html) pour vendre la bande passante de ses utilisateurs gratuits en tant que nœuds de sortie. La différence réside maintenant principalement dans l'échelle et l'acheteur. Avec des défenses anti-bots sophistiquées de sociétés comme **Cloudflare** et **DataDome** bloquant les IP de centres de données, les scrapers basés sur l'IA acheminent de plus en plus le trafic via des connexions résidentielles. **Krebs** [a rapporté en octobre 2025](https://krebsonsecurity.com/2025/10/aisuru-botnet-shifts-from-ddos-to-residential-proxies/) sur des botnets comme **Aisuru** alimentant la récolte de données d'IA à grande échelle, et **Google** [a démantelé le réseau de proxys criminels IPIDEA](https://thehackernews.com/2026/01/google-disrupts-ipidea-one-of-worlds.html) en janvier. Bien que ces opérations détournent des appareils, **Bright Data** maintient que ses nœuds de sortie sont opt-in, faisant de la significativité de ce consentement une question centrale. **Lowpass**, syndiqué par **The Verge**, [a d'abord mis en lumière](https://www.lowpass.cc/p/smart-tv-web-scraping-ai-bright-data-proxy-networks) l'angle des téléviseurs intelligents en février, la recherche actuelle fournissant l'analyse technique approfondie. Suite à ces révélations, **Google**, **Amazon** et **Roku** ont restreint les SDK de proxy en arrière-plan, conduisant **Bright Data** à abandonner le support pour ces plateformes, bien qu'il liste toujours **Tizen de Samsung** et **webOS de LG**. ### Que faire Pour les professionnels de la sécurité informatique et les utilisateurs soucieux de leur vie privée, ce trafic est relativement simple à identifier et à bloquer. Sur un réseau domestique, l'approche la plus directe consiste à bloquer les adresses Web spécifiques utilisées par le SDK au niveau du routeur, en utilisant des outils tels que **Pi-hole** ou **NextDNS**. Les domaines clés à bloquer comprennent `proxyjs.brdtnet.com`, `proxyjs.luminatinet.com`, `proxyjs.bright-sdk.com`, `clientsdk.bright-sdk.com` et `clientsdk.brdtnet.com`. Selon la recherche, le blocage de ces adresses empêchera les appareils d'agir comme relais sans affecter les services payants de **Bright Data**, qui fonctionnent sur une infrastructure distincte. Les organisations gérant les appareils mobiles des employés devraient également envisager de scanner les applications contenant ce SDK. Un point crucial à retenir est que sur les connexions de données mobiles, ce trafic peut contourner le Wi-Fi d'entreprise, ce qui signifie que les blocages au niveau du réseau seuls peuvent ne pas toujours être suffisants. De plus, **Bright Data** pourrait potentiellement modifier les méthodes de connexion du SDK à l'avenir, nécessitant des mises à jour continues des listes de blocage.