लिविंग रूम का स्मार्ट TV AI scraping economy का एक node है

(blog.includesecurity.com)

3 पॉइंट द्वारा GN⁺ 2026-06-07 | 2 टिप्पणियां | WhatsApp पर शेयर करें

उपभोक्ता apps में एम्बेड किया गया Bright Data SDK, उपयोगकर्ता की सहमति के तहत फोन या smart TV को residential proxy exit node में बदल देता है, और ग्राहकों के web scraping traffic को घरेलू IP के ज़रिए route करता है
Residential proxy ऐसे माहौल में bypass का साधन है जहाँ Cloudflare, DataDome, HUMAN आदि ज्ञात cloud IP requests को सीमित या block करते हैं, और target sites तक भुगतान करने वाले residential customers के IP से पहुँचता है
connected TV में battery की सीमा नहीं होती, वे हमेशा Wi‑Fi से जुड़े रहते हैं और standby में 24/7 चलते हैं, इसलिए फोन की तुलना में हमेशा उपलब्ध रहने और बिना निगरानी पड़े रहने की proxy शर्तें बेहतर होती हैं
iOS SDK बिना authentication वाले configuration endpoint से idle criteria, bandwidth limits, और partner list लेता है, और WebSocket peer tunnel खोलकर device-state telemetry और cmd_tun scraping jobs को संभालता है
defense का केंद्र proxyjs.* और clientsdk.* DNS blocking, SNI filtering, TLS certificate fingerprint detection, और MDM app binary scan हैं; iOS का use_netifs VPN-आधारित visibility को bypass करने वाली एक सीमा है

अवलोकन

AI क्षमता बढ़ाने के लिए data center निर्माण के खिलाफ community-स्तर के विरोध से अलग, घर के अंदर मौजूद devices को AI training के लिए distributed data collection में इस्तेमाल किया जा सकने वाला एक ढांचा मौजूद है
Bright Data, 400M+ घरेलू IP addresses वाले residential proxy network की access बेचता है, जिसके जरिए ग्राहक web scraping traffic route करते हैं; इसका source consumer apps में embedded SDK है
यह SDK उपयोगकर्ता की सहमति के तहत फोन या smart TV को exit node में बदल देता है; विश्लेषण का विषय है SDK कैसे काम करता है, किन platforms पर deploy होता है, और internet-connected TV AI models के लिए web scraping proxy के रूप में क्यों उपयुक्त हैं

यह अभी क्यों महत्वपूर्ण है

AI कंपनियाँ pretraining, search·retrieval augmentation, agent grounding, और search features के लिए web-scraped content पर निर्भर हैं
आज का web ऐसा वातावरण है जिसे data center से आसानी से scrape नहीं किया जा सकता, और Cloudflare, DataDome, HUMAN जैसे प्रदाता ज्ञात cloud IPs से आने वाले requests को सीमित या block करते हैं
इसका विकल्प है residential proxy, जो Comcast या T-Mobile subscribers के connection जैसे भुगतान करने वाले residential customers के IP से target sites तक पहुँचता है
अक्टूबर 2025 की Krebs रिपोर्ट का उद्धरण कहता है: “Aisuru और अन्य sources से proxies की अधिकता कई AI projects से जुड़े बड़े पैमाने के data-harvesting प्रयासों को बढ़ावा दे रही है”
2019 तक पीछे जाने वाला academic measurement दिखाता है कि ऐसे networks का भारी स्तर पर दुरुपयोग होता है, और FBI ने भी इस साल की शुरुआत में official advisory जारी की
अब तक की अधिकांश रिपोर्टिंग ने Aisuru और Kimwolf जैसे botnets, PROXYLIB जैसे trojanized apps, और IPIDEA जैसे pre-infected IoT hardware सहित अवैध residential proxy supply पर ध्यान दिया है
वैध supply पक्ष की अपेक्षाकृत कम जाँच हुई है, और Bright Data अपने marketing मानकों के अनुसार दुनिया का सबसे बड़ा residential proxy network होने का दावा करते हुए partner apps में embedded consent SDK पर आधारित “150M+ IPs” का प्रचार करता है

connected TV आदर्श proxy क्यों हैं

कारक	फोन	smart TV / CTV
पावर	दिन का अधिकांश समय battery पर	हमेशा power से जुड़ा
नेटवर्क	Wi‑Fi + cellular	हमेशा Wi‑Fi, high-speed
uptime	रुक-रुक कर	standby में 24/7
bandwidth limit	कम, cellular limits	लगभग असीमित
उपयोगकर्ता का ध्यान	सक्रिय उपयोग	अक्सर बिना देखरेख के
consent UI	फोन स्क्रीन पर text	TV remote के arrow keys से navigate किया जाने वाला text
enterprise·family supervision	MDM, mobile EDR आदि अधिक	लगभग नहीं के बराबर

TV ऐसे devices हैं जो 1% battery तक नहीं पहुँचते, बार-बार Wi‑Fi networks के बीच नहीं घूमते, और उपयोगकर्ता के सो जाने के बाद lock नहीं होते
कुछ partner publishers अपनी privacy policy में Bright Data के साथ संबंध का खुलासा करते हैं; PlayWorks privacy policy इसका एक उदाहरण है
privacy policy disclosure, TV के लिए उपयुक्त control point नहीं है; remote के arrow keys से कानूनी दस्तावेज़ scroll करना कठिन है, और in-app consent dialog की संरचना यह नहीं बताती कि भुगतान करने वाले Bright Data customers उपयोगकर्ता के घर के internet के जरिए scraping traffic route करेंगे
The Verge ने document किया है कि Roku app Petflix की opt-in screen में लिखा है: “विज्ञापन कम करने और मुफ्त में आनंद लेने के लिए, Bright Data को आपके device के spare resources और IP address का कभी-कभी उपयोग कर internet के public web data डाउनलोड करने की अनुमति दें”
Petflix dialog “कभी-कभी” शब्द का उपयोग करता है, लेकिन publicly queryable SDK configuration में max_bw_monthly_wifi: 200,000,000,000 का मतलब है प्रति माह default Wi‑Fi budget 200GB

Bright Data ने जिन targets को partner के रूप में नामित किया

Bright Data एक partner manifest endpoint expose करता है जिसे बिना authentication कोई भी fetch कर सकता है
सार्वजनिक sources के आधार पर उच्च-विश्वसनीयता वाले identification items

Partner ID	Entity	पैमाना
`playworks_digital`	PlayWorks Digital Ltd	400+ CTV game titles, Comcast·Sky·Cox·LG·Samsung·Vizio·Roku के जरिए लगभग 250M TV households तक पहुँच
`cloudtv`	CloudTV	125+ TV brands और 15+ OEMs में integration
`longvision_media_hong_kong_co_limited`	Longvision Media HK (LongTV)	Hong Kong·Malaysia में 5M OTT users
`viber_media_s_r_l`	Viber Media S.à r.l. (Rakuten)	Viber messenger के 250M–820M monthly users
`supercent_inc`	Supercent	2023 downloads के आधार पर Korea का नंबर 1 mobile publisher
`moonfrog_labs_private_limited`	Moonfrog Labs	केवल Teen Patti Gold के लगभग 10M MAU, 90 million dollar में acquired
`hola_networks`	Hola Networks	Bright Data की lineage में parent company, और Hola के historical marketing मानकों के अनुसार peak users कई दसियों millions से लगभग 100M+ की range में

desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp manifest में मौजूद हैं, लेकिन इन्हें सार्वजनिक स्रोतों से पहचानना कठिन है
bright_screensavers, bright_videos, brightdata खुद Bright Data के ऐप हैं
Bright Data settings में नाम होने से यह संकेत मिलता है कि किसी समय integration हुआ हो सकता है, लेकिन यह इस बात का प्रत्यक्ष प्रमाण नहीं है कि किसी खास publisher के अभी वितरित किए जा रहे ऐप्स production environment में SDK शामिल करते हैं
partner list सीधे तौर पर यह साबित करती है कि Bright Data बिना authentication वाले public endpoint पर यह सूची वितरित करता है, और PlayWorks·CloudTV·Longvision जैसे कम-से-कम तीन CTV-केंद्रित व्यवसायों ने user devices को residential proxy exit node के रूप में monetize किया
PlayWorks अपने marketing materials के अनुसार प्रमुख TV platforms और ISP ecosystem में CTV deployment तथा सैकड़ों मिलियन households तक पहुंच के आंकड़े पेश करता है

Bright Data SDK उपयोगकर्ता डिवाइस को residential proxy exit node में कैसे बदलता है

Bright Data SDK एक सार्वजनिक रूप से documented commercial product है, जिसमें publishers के लिए SDK integration documents और web के लिए JavaScript variant मौजूद हैं
यह विश्लेषण deploy किए गए iOS framework की reverse engineering और 30 दिनों की runtime traffic instrumentation पर आधारित है
SDK को partner app के भीतर iOS framework brdsdk.framework के रूप में वितरित किया जाता है
बिना authentication वाला configuration
- SDK हर बार चलने पर नीचे दिया गया request call करता है
- GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
- यह endpoint किसी सार्थक authentication के बिना काम करता है, और server केवल दो query parameters की जांच करता है: app bundle ID appid और SDK version string ver
- अगर partner app की App Store listing से मिलने वाला bundle ID, SDK version string और किसी भी तरह generate किया गया UUID दिया जाए, तो यह वही configuration लौटाता है जो असली device को मिलता है
- response में feature flags, battery ratio·CPU/memory limits·Wi‑Fi/cellular rules जैसे idle detection thresholds, country-specific bandwidth tiers, और partner manifest शामिल संरचना होती है
- configuration में वे idle rules मौजूद हैं जिनसे device traffic relay की eligibility पाता है, VPN के आसपास peer traffic route करने वाले flags, cross-platform installations को एक पहचान से जोड़ने वाला map, और country-specific bandwidth limits शामिल हैं
Peer tunnel
- configuration लाने के बाद SDK नीचे दिए गए पते पर एक persistent WebSocket खोलता है
- wss://proxyjs.brdtnet.com:443
- लिखे जाने के समय यह hostname AWS Global Accelerator IP 3.33.193.183, 15.197.193.114 पर resolve होता है
- TLS certificate CN=*.luminatinet.com है, और Luminati Networks, Bright Data का 2018 से पहले का कंपनी नाम था
- 2018 rebranding के बाद भी active SDK infrastructure legacy certificates का उपयोग करती है, और luminatinet.com या brdtnet.com traffic ग्राहक-पक्ष Bright Data उपयोग नहीं बल्कि peer tunnel plane की पहचान का संकेत है
- मौजूदा customer-facing proxy service brightdata.com brand domain पर चलती है, इसलिए network में luminatinet.com·brdtnet.com traffic peer tunnel plane को दर्शाता है
- server खुद को uWebSockets: 20 के रूप में पहचानता है
- peer endpoint upgrade के लिए authentication नहीं मांगता, valid TLS WebSocket upgrade स्वीकार करने के बाद तुरंत application-layer frame भेजता है जो client का public IP वापस देता है
- handshake flow
- 1. server → client tunnel_init: session बनाता है और client का public IP लौटाता है
- 1. server → client cid_set: <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> format का session-tracking identifier assign करता है, और पुष्टि हुई कि यह वास्तविक device telemetry के cid field से मेल खाता है
- 1. server → client status_get: device की idle state, battery, network type, available bandwidth को poll करता है, और device 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 आदि लगातार telemetry के साथ जवाब देता है
- 1. handshake पूरा होने के बाद अगर device अनुकूल स्थिति report करे, तो server की task-matching layer cmd_tun frame push कर सकती है, जिसे SDK उपयोगकर्ता के residential IP को source बनाकर third-party site के HTTP requests चलाने में इस्तेमाल करता है
- WebSocket के सभी frames एक fixed envelope वाले plain JSON हैं
- {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
- binary से निकाले गए और वास्तविक communication में सत्यापित commands
- | दिशा | cmd | उद्देश्य |
- |---|---|---|
- | Server → Client | tunnel_init | session खोलना, public IP echo |
- | Server → Client | cid_set | session identifier assign करना |
- | Server → Client | status_get | device idle·battery·bandwidth poll करना |
- | Server → Client | cmd_tun / tun | scraping task deliver करना |
- | Server → Client | dns | target DNS resolution request |
- | Server → Client | consent | consent status request |
- | Client → Server | status_send | device state periodic heartbeat |
- | Client → Server | tun_report / tun_ack / tun_fin | relay task lifecycle response |
- | Client → Server | tunnel_init_decline | session अस्वीकार |
- | Client → Server | logs | diagnostic logs server को भेजना |
- message signing, HMAC, client certificate, या device attestation नहीं है, और वास्तविक tasks पाने वाले peers को अलग करने वाले तत्व सिर्फ TLS layer और server का IP reputation filter हैं
- commercial malware protocol design से परिचित पाठकों के मानक से देखें तो इसकी security level सामान्य C2 से भी व्यवहारिक रूप से कम है
वे शर्तें जिन्हें SDK “idle” मानता है
- configuration उन device state rules को निर्दिष्ट करती है जिनमें दूसरे लोगों का traffic relay किया जा सकता है
```
"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
}
```
- ignore_screen_on और ignore_on_call flags की वजह से “idle” का मतलब यह नहीं है कि उपयोगकर्ता device से दूर है, बल्कि यह कि CPU·memory·battery SDK thresholds के भीतर हैं
- अगर उपयोगकर्ता call पर हो या screen को सक्रिय रूप से पढ़ रहा हो, तब भी उसे relay उद्देश्य के लिए idle state माना जाता है
Cross-platform identity linking
- configuration में नीचे दिया गया dual_pairing map मौजूद है
```
"dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
```
- यह map एक ही brand के iOS, Windows, और macOS installations को server-side linking structure के जरिए एक इकाई में बांधता है
- http3_enabled: true field QUIC-based peer transport के लिए flag है, और भविष्य के versions peer tunnel को TCP/443 से UDP/443 पर ले जा सकते हैं
- जो defenders TCP connection tracking से WebSocket detect करते हैं, उनकी detection method UDP/443 migration होने पर टूट सकती है
Inspection bypass
- SDK configuration का use_netifs: true flag वह शर्त है जिसमें SDK binary code system default path की जगह किसी specific required interface के साथ NWConnection configure करता है
- required interface Wi‑Fi का en0 या cellular का pdp_ip0 है
- iOS पर यह तरीका configured VPN के tun0 interface को पूरी तरह bypass करता है, इसलिए भले ही app का बाकी HTTPS traffic VPN से गुजरे, peer tunnel उपयोगकर्ता द्वारा configured VPN से नहीं गुजरता
पारदर्शी TLS interception शोध वातावरण ने SDK की सभी HTTPS calls को capture किया, लेकिन port 443 को स्पष्ट रूप से inspector की ओर redirect किए जाने के बावजूद proxyjs.brdtnet.com:443 peer tunnel को capture नहीं कर सका
- bypass Apple के प्रलेखित NWParameters.requiredInterface API का उपयोग करता है
- SDK दो स्वतंत्र inspection bypass का उपयोग करता है
- Control plane: config fetch और telemetry ping, URLSession·NSURLConnection की जगह CFNetwork के CFHTTPMessage primitives पर आधारित हैं, जिससे mobile app security tools में आम URLSession-स्तर instrumentation, swizzling, network extension, URLProtocol subclass निष्प्रभावी हो जाते हैं, जबकि system proxy का सम्मान बना रहता है, इसलिए TLS interception शोधकर्ताओं के लिए visibility बनी रहती है
- Data plane: peer tunnel NWConnection पर आधारित है, जिसमें physical interface को required interface के रूप में सेट किया गया है, जिससे VPN निष्प्रभावी हो जाता है और scraping के residential IPs से चलने की गारंटी मिलती है
- MDM, enterprise VPN-आधारित traffic inspection, home router parental controls का उपयोग करने वाली security teams के लिए सबसे संवेदनशील channel को visibility layer को bypass करने के लिए डिज़ाइन किया गया है

देश-विशिष्ट स्तर

सेटिंग्स में देश-विशिष्ट bandwidth thresholds मौजूद हैं

देश	relay के लिए न्यूनतम बैटरी	दैनिक सीमा	मासिक सीमा
Uzbekistan	1%	1GB	30GB
Oman	1%	1GB	30GB
Qatar	20%	40MB	250MB
UAE	20%	40MB	250MB
default, worldwide	20%	50MB	500MB

Uzbekistan और Oman के डिवाइसों में बैटरी 1% तक relay की अनुमति है, और दैनिक सीमा default मान की 20 गुना तथा मासिक सीमा default मान की 60 गुना है
Qatar और UAE के डिवाइसों पर default मान से कम सीमा लागू है
देश-विशिष्ट स्तर इस तरह क्यों बनाए गए हैं, यह निश्चित रूप से नहीं कहा जा सकता; केवल अनुमान ही लगाए जा सकते हैं
वैश्विक default allowance भी उपयोगकर्ता के घरेलू इंटरनेट के जरिए हर महीने दूसरे लोगों के 500MB traffic को अनुमति देता है

टेस्ट सेटअप और methodology

30 दिनों तक consent के साथ इंस्टॉल किए गए partner app चलाने वाले iOS डिवाइस पर TLS interception proxy capture किया गया, और example app में Bright SDK एम्बेड करने वाला XYO COIN शामिल था
brdsdk.framework version 1.532.120, iOS arm64 binary पर static analysis किया गया
Bright Data के specific hostname, certificate fingerprint, और TLS infrastructure को वही request करने वाला कोई भी व्यक्ति सार्वजनिक रूप से observe कर सकता है
research fleet या research client के session-by-session पहचान डेटा दस्तावेज़ में नहीं है

टाइमलाइन

11 मई 2026 को privacy@brightdata.com पर planned publication notification email भेजा गया
publication के समय तक उस notification पर कोई response नहीं मिला

defense approaches

traffic नेटवर्क boundary पर स्पष्ट fingerprint छोड़ता है, और SDK app binary में identifiable symbols छोड़ने वाली संरचना रखता है
approach 1, DNS blocking, नेटवर्क के जरिए route होने वाले डिवाइसों के लिए सरल और प्रभावी तरीका है
- proxyjs.brdtnet.com
- proxyjs.luminatinet.com
- proxyjs.bright-sdk.com
- clientsdk.bright-sdk.com
- clientsdk.brdtnet.com
proxyjs.* को block करने से peer tunnel रुक जाता है, और इससे उन ग्राहकों पर कोई असर नहीं पड़ता जो दूसरे domain पर चलने वाली Bright Data customer-facing proxy service का वैध रूप से उपयोग करते हैं
approach 2, TLS SNI filtering, server_name का *.brdtnet.com, *.luminatinet.com, *.luminati.io से match होने वाले TLS handshake को block या warn करने का तरीका है
SNI filtering बिना TLS inspection के नेटवर्क boundary पर काम करती है
approach 3, TLS certificate fingerprint detection, निम्न fingerprint के आधार पर block या warn करती है
- .brdtnet.com → SHA256 313ce4ec7d5a51e5…
- .luminatinet.com → SHA256 5028612e625befea…
certificate fingerprint, Sectigo certificate replacement होने तक स्थिर रहते हैं, और वर्तमान certificate 2026 के मध्य तक valid हैं
use_netifs से जुड़ी सीमाओं के कारण ये तीनों स्तर केवल तब काम करते हैं जब traffic नेटवर्क boundary से होकर गुजरता है
जब iOS डिवाइस cellular का उपयोग करता है, तब SDK की use_netifs binding ऐसी स्थिति बनाती है जिसमें peer traffic corporate Wi‑Fi को पूरी तरह bypass कर देता है
managed device fleet के लिए पूरक नियंत्रण MDM-आधारित app binary scan है, जिसमें इंस्टॉल किए गए app में Swift symbols BrdWebSocketFacade और BrdNetwork.DNSResolver खोजे जाते हैं, और जिन app में ये symbols हों उन्हें company-issued डिवाइसों पर प्रतिबंधित किया जाता है
जिन घरेलू उपयोगकर्ताओं को किसी विशेष smart TV या mobile app को लेकर चिंता है, वे router DNS settings में ऊपर दिए गए hostname block कर सकते हैं
blocking tools के उदाहरण: Pi-hole, NextDNS, Cloudflare Gateway, ISP की equivalent सुविधाएँ

2 टिप्पणियां

GN⁺ 2026-06-08

Hacker News की राय

settings लाने के बाद SDK wss://proxyjs.brdtnet.com:443 पर हमेशा चालू WebSocket खोलता है, और यह hostname AWS Global Accelerator IP पर resolve होता है
इसमें एक विडंबना है कि scraper और जिन websites को scrape किया जा रहा है, दोनों के AWS पर host होने की अच्छी संभावना है, जबकि वे एक-दूसरे से असंबद्ध होने का दिखावा करते हुए एक परिष्कृत cat-and-mouse game खेल रहे हैं
- Cloudflare DDoS control panels को भी DDoS defense services बेचता है
- Bright Data का product AWS Marketplace पर भी listed है
  https://aws.amazon.com/marketplace/seller-profile?id=bf9b432...
- इसे तुरंत DNS blocklist में जोड़ दिया
- यह उस ढांचे जैसा है जहाँ अमेरिकी सरकार को ऐसी commercial कंपनियों की ज़रूरत होती है जिन्हें वह ठीक से regulate नहीं करती, और वे कंपनियाँ privacy violations को मानो वैध साधन की तरह उपलब्ध कराती हैं, ताकि सरकार हाथ झाड़ सके
मैं किसी भी smart device को Wi‑Fi से connect नहीं करता। अगर वह connection के बिना काम नहीं करता, तो मुझे वह नहीं चाहिए
TV को मैं सिर्फ display device की तरह इस्तेमाल करता हूँ, और सिर्फ HDMI input होना काफ़ी है
- मेरे पास एक smart TV है जिसने factory से निकलने के बाद कभी internet से बात नहीं की, लेकिन यह मुझे काफ़ी अस्थिर संतुलन लगता है
  डर है कि कोई मेहमान HDMI स्क्रीन के ऊपर कुछ सेकंड के लिए दिखने वाला “Services unavailable, press [menu] to troubleshoot” toast देखकर मदद करने के इरादे से उसे connect न कर दे। फिर एक साथ 4–5 साल के firmware updates आ जाएँगे, HDMI feed से जैसे-तैसे निकालकर जमा किया गया आधे दशक का viewing data इसी पल के लिए भेज दिया जाएगा, और हर तरफ ads उभरने लगेंगे
  भले ही अभी ऐसा न हो, मुझे लगता है कि OS के बहुत अंदर कहीं makeEverythingWorse जैसा कोई flag होगा, जो The Beast को थोड़ा ऊँचा patch number सूँघते ही femtosecond में चालू हो जाएगा। अंत में बस यह होगा कि Samsung के किसी व्यक्ति को बता दिया जाएगा कि मेरा पसंदीदा program HDMI2 है, और उसके बाद चीज़ टूट चुकी अवस्था में रह जाएगी
  मैं अपनी माँ के TV पर भी उसे उस खाई के किनारे से वापस ला चुका हूँ, इसलिए यह चिंता वाजिब लगती है। खाली TV home screen और लकीरों वाला broadcast tower icon जैसे लुभाते हैं: “हमारे पास भी Disney+ और CraveTV हैं… [menu] दबाइए… coffee table पर आपके बेटे ने जो note चिपकाया है, उसे नज़रअंदाज़ कीजिए”
- कोई बात नहीं। Amazon Sidewalk जैसी tech और सस्ते, हल्के 4G/5G modules के साथ अब किसी को connection की अनुमति माँगने की ज़रूरत ही नहीं है
  आप पुराने devices इस्तेमाल कर सकते हैं, लेकिन आप पीछे नहीं रहना चाहेंगे, है न। अगर आप इस digital जुए को बस स्वीकार नहीं करते, तो आपके आसपास के लोग सोचेंगे कि आप गरीब हैं या C.H.U.D. हैं
- मैं इस सिद्धांत को सैद्धांतिक रूप से समझता हूँ, लेकिन आधुनिक जीवन में, जहाँ आप TV पर Netflix या YouTube जैसी चीज़ें देखना चाहते हैं, यह व्यवहार में कैसे चलेगा, समझ नहीं आता
  चाहे वह TV हो या Android box, आखिरकार कहीं न कहीं आप किसी third party पर भरोसा कर रहे होते हैं, और ऐसे software पर भी जो उसके ऊपर दूसरी third-party apps चला सके। विकल्प है local Jellyfin server, लेकिन उसमें वह content डालने के लिए जिसे परिवार देखना चाहता है, बहुत अधिक संभावना है कि आपको कानून तोड़ना पड़ेगा
  व्यक्तिगत रूप से तो मैं चाहूँगा कि घर में TV ही न हो, लेकिन परिवार को मनाना आसान नहीं है ;-)
- मेरे TCL TV में जिन Google policies से सहमत होना होता है, उन्हें पढ़ने के लिए पहले connect करना पड़ता है। connect न करें तो बिना पढ़े policy मान लेने जैसी स्थिति है
  शुक्र है कि connectivity न होने पर इससे होने वाला वास्तविक नुकसान लगभग शून्य है
- झुंझलाहट की बात यह है कि TV को network से connect करके मिलने वाली कुछ सुविधाएँ मुझे चाहिए भी। खासकर TV power on करना या input select करना जैसी चीज़ों को TV द्वारा expose की गई API से control करना
  अगर उसे ऐसे VLAN में डालें जहाँ external internet access blocked हो, तो यह manage किया जा सकता है, लेकिन यह तथ्य कि ऐसा करना पड़ता है, अपने आप में बहुत परेशान करने वाला है
सिद्धांत रूप में local network पर TV को block करना अच्छा है। लेकिन क्या Amazon Fire devices ने कुछ समय तक Sidewalk का इस्तेमाल करके mother ship तक जाने का रास्ता नहीं बनाया था?
पड़ोसी की Ring doorbell अगर बस default settings पर भी रहती, तो वह काफ़ी होता
SDK setting में use_netifs: true flag है, और SDK binary में यह flag NWConnection बनाते समय system default route की जगह किसी खास required interface, जैसे en0 (Wi‑Fi) या pdp_ip0 (cellular), को निर्दिष्ट कर देता है
iOS पर इसकी वजह से configured VPN का tun0 interface पूरी तरह bypass हो जाता है। भले ही app का बाकी HTTPS traffic VPN से गुज़रे, peer tunnel उपयोगकर्ता द्वारा configured VPN से नहीं गुजरता
इस API का वैध उपयोग मामला क्या हो सकता है? ऐसा कब और क्यों होना चाहिए कि app को उपयोगकर्ता द्वारा configured VPN को bypass करने दिया जाए?
- वैध उपयोग मामला यह होगा कि वह app खुद VPN प्रदान करने वाला application हो, या ऐसा app हो जिसे दुनिया भर में पहुँचने योग्य target की बजाय local-nearby network में किसी चीज़ से communicate करना हो
- जब full tunneling अस्थायी रूप से काम नहीं कर रही हो, तो split tunneling से VPN के कारण आई समस्याओं को bypass किया जा सकता है
  लेकिन मेरा मानना है कि apps को network boundaries जैसी चीज़ों को bypass नहीं करना चाहिए
यह शायद भोला सवाल है, लेकिन अगर मैं सीखना चाहूँ कि अपने devices—ज़्यादातर iOS—या home network पर ऐसी चीज़ें कैसे detect करें, तो मुझे क्या search करना चाहिए?
मैं अपने devices पर उन apps को ढूँढकर हटाना चाहता हूँ जिनमें यह SDK active है
- शायद इससे बेहतर resources हों, लेकिन अगर आपके पास Mac भी है, तो पहली नज़र में यह लेख ठीक लगा
  https://www.thequantizer.com/tutorials/wireshark-iphone-traf...
  व्यक्तिगत रूप से मुझे ऐसी tracing किए काफ़ी समय हो गया है, लेकिन Wireshark इस्तेमाल करना बहुत आसान था, और network expose हो जाने पर online संदर्भ जानकारी भी काफ़ी मिल जाती है
  VPN को bypass करना विशेष रूप से भयानक था, और कुल मिलाकर पूरी चीज़ ही ऐसी है। व्यक्तिगत रूप से मैं चाहूँगा कि service terms में कितनी सामग्री डाली जा सकती है, उसकी कोई सीमा हो। अब कोई भी इतना सारा पाठ पढ़ना नहीं चाहता
प्रस्तावित mitigation काफ़ी कमज़ोर लगते हैं
DNS blocking और SNI filtering के बारे में लगता है कि अगर इस मुद्दे पर काफ़ी ध्यान गया, तो Bright Data endpoints घुमाना शुरू कर देगा। SDK को शामिल करने वाले सभी apps को उसके पीछे आने में समय लगेगा, लेकिन अगर वे चतुर हैं, तो संभव है कि SDK में पहले से ही एक backup command-and-control connection हो, जिसे वह तब आज़माए जब मौजूदा endpoint तक लंबे समय तक पहुँचना संभव न हो
TLS fingerprinting को बदलते रहना सबसे सस्ता तरीका है, जब तक SDK उसे pin न करे
MDM solutions आम users के लिए लगभग पहुँच से बाहर हैं, और यह भी स्पष्ट नहीं है कि SDK का नाम कितना स्थिर है कि उस पर भरोसा किया जा सके
इसका मतलब यह नहीं कि कोई बेहतर approach मेरे पास है। बस इतना लगता है कि Apple और Google को इस तरह के व्यवहार पर स्पष्ट रोक लगानी चाहिए और publisher accounts तुरंत बंद कर देने चाहिए
मेरा firewall बाहरी दुनिया की पहुँच को ब्लॉक नहीं करना चाहिए। लेकिन Home Assistant के control को अनुमति होनी चाहिए
- बहुत-से smart TVs में ads built-in होते हैं। मैंने एक used Sony Bravia खरीदी थी, और तीन चिढ़ाने वाले दिनों के भीतर उसे सड़क किनारे रख दिया
  क्योंकि वह boot loop में फँस गई थी और UI input lag लगभग 3 सेकंड का था। मैंने उसे कभी network से जोड़ा भी नहीं था, फिर भी उसने बड़ी मेहरबानी से Sony studio films के ads दिखाए, जो TV के बनने के समय, यानी लगभग 10 साल पहले, रिलीज़ हो रहे थे
अभी जाँचकर देखा, मैं पूरे network पर AdGuard चला रहा हूँ। TV पर 80% requests block हो रही हैं, और पूरे network में लगभग 50% block हो रही हैं। यह पागलपन है
अगर इस तरह का proxy illegal नहीं है, तो कम से कम होना चाहिए। यह internet routing और IP address leasing तथा ownership के बुनियादी assumptions को दरकिनार करने की सीमा पर है; और यह कहना भी शायद कमज़ोर होगा, Bright Data ने इसे बाकायदा एक billable product की तरह पैक कर दिया है
इसमें लिखा है: “आप Bright Data को कभी-कभी आपके device के spare resources और IP address का उपयोग करके internet से public web data डाउनलोड करने की अनुमति देते हैं”
end user के लिए भ्रामक हिस्सा “public web data डाउनलोड” वाला वाक्यांश है। अगर data public है, तो Bright Data उसे खुद डाउनलोड क्यों नहीं कर सकता? शायद इसलिए कि दूसरी तरफ़ वाला ऐसा नहीं चाहता। यह product असल में user से यह काम करवाता है कि वह Bright Data की मदद करे, ताकि वह किसी ऐसे व्यक्ति की तरफ़ से, जिसके पास पैसे हैं लेकिन जो internet पर वैध कारणों से नुकसान में है, “public” data provider की अनचाही properties को bypass कर सके
यह पूरी तरह निंदनीय है, लेकिन सच कहूँ तो मैं न तो चकित हूँ, न बहुत चिंतित, क्योंकि मुझे पता था कि चीज़ें इसी दिशा में जा रही हैं। लोग बहुत पहले से अपने बटुए से वोट करते आए हैं। यहाँ proxy के रूप में इस्तेमाल होने वाला कोई privacy-conscious Joe the Hacker नहीं है, बल्कि हमारे माता-पिता, दिन भर के बाद सिर्फ़ थोड़ा मनोरंजन चाहने वाले लाखों लोग, और छोटे बच्चों के माता-पिता हैं
दिन-ब-दिन dark internet theory ज़्यादा plausible लगने लगी है, और सच कहूँ तो अगर चीज़ें उस दिशा में जाएँ तो मुझे ठीक ही लगेगा। internet एक ऐसे feudal internetwork में टूट जाएगा जहाँ किसी भी routing के लिए हर hop पर key चाहिए होगी, और शायद तभी असली लोग—और सच कहें तो agents भी—उस trust का कुछ हिस्सा बचा पाएँगे जिसे अभी सक्रिय रूप से bypass किया जा रहा है
- यह पूरी तरह legal है, और IP routing और address ownership के बारे में जैसा आपने कहा, वैसा कोई कानून मौजूद नहीं है
यहाँ दिखने वाली समस्याओं में से एक वही है जो Tor exit node चलाने पर होती है। कोई malicious user इसे अपनी location छिपाने के लिए इस्तेमाल कर सकता है
बस यह कल्पना कीजिए कि असली अपराधी वह व्यक्ति है जो आपके TV को proxy की तरह इस्तेमाल करके child sexual abuse material का व्यापार कर रहा है, और police आपके घर इस निष्कर्ष पर पहुँचकर आ जाए कि आप ही उसका distribution कर रहे हैं
- मुझे सच में नफ़रत है कि सब कुछ users के ख़िलाफ़ होता जा रहा है। आपको लगभग हर चीज़ का expert बनना पड़ता है, और यह देखने के लिए लगातार news ट्रैक करनी पड़ती है कि कहीं कोई बड़ा बदलाव तो नहीं आ गया जो पुरानी धारणाओं को उलट दे
  और अगर किसी तरह आपसे वह छूट जाए और आप शिकायत करें, तो defenders झुंड बनाकर आ जाते हैं—या तो बचाव करते हैं, या बात घुमा देते हैं, या discussion को पटरी से उतार देते हैं
  कम से कम अच्छी बात यह है कि यह थकान अब आम लोगों तक भी पहुँच रही है। मेरे एक सहकर्मी ने शिकायत की कि बच्चों पर सही restrictions और limits लागू करने के लिए उसे खुद पूरा Wi-Fi/internet administrator बनना पड़ रहा है
  बस झुंझलाहट में कह रहा हूँ। यहाँ सही समाधान क्या है, यह अभी भी मुझे साफ़ नहीं है
- Bright Data जैसे groups के पास customer verification procedures काफ़ी अच्छे होते हैं। police की एक डरावनी visit के बाद असली अपराधी जेल में होगा

GN⁺ 2026-06-07

Lobste.rs की रायें

इस प्रोटोकॉल की बात करते हुए, अगर ऐसा reverse honeypot बनाया जाए जो हर request पर स्वेच्छा से random generated कचरा data दे, तो बचे हुए tokens वाले किसी व्यक्ति के लिए यह एक मज़ेदार vibe coding प्रोजेक्ट बन सकता है
- प्रोटोकॉल को वास्तव में implement करने की ज़रूरत भी नहीं लगती। logs देखें तो इन residential proxies में से काफ़ी अपने आपको छिपाने में पूरी तरह नाकाम रहते हैं, इसलिए बस आसानी से कचरा data बाहर भेजा जा सकता है
  vibe coding की भी ज़रूरत नहीं, और ऐसा काम करने वाले tools पहले से दर्जनों हैं। उनमें से काफ़ी 1 साल से ज़्यादा समय से ऐसे proxies को लगातार अंतहीन कचरा data देते आ रहे हैं
मुझे बिल्कुल समझ नहीं आता कि TV हो या कोई और appliance, उसे इंटरनेट से क्यों जोड़ा जाए। ऐसा करने की कोई अच्छी वजह नहीं है
- लोग TV पर streaming services देखते हैं। TV को इंटरनेट से जोड़ना यह करने का सबसे आसान तरीका है

लिविंग रूम का स्मार्ट TV AI scraping economy का एक node है

अवलोकन

यह अभी क्यों महत्वपूर्ण है

connected TV आदर्श proxy क्यों हैं

Bright Data ने जिन targets को partner के रूप में नामित किया

Bright Data SDK उपयोगकर्ता डिवाइस को residential proxy exit node में कैसे बदलता है

बिना authentication वाला configuration

Peer tunnel

वे शर्तें जिन्हें SDK “idle” मानता है

Cross-platform identity linking

Inspection bypass

देश-विशिष्ट स्तर

टेस्ट सेटअप और methodology

टाइमलाइन

defense approaches

संबंधित पढ़ाई

2 टिप्पणियां

Hacker News की राय

Lobste.rs की रायें