거실의 스마트 TV는 AI 스크래핑 경제의 노드

• 소비자 앱에 삽입되는 Bright Data SDK는 사용자 동의 아래 휴대폰이나 스마트 TV를 주거용 프록시 출구 노드로 전환하고, 고객의 웹 스크래핑 트래픽을 가정용 IP로 라우팅
• 주거용 프록시는 Cloudflare, DataDome, HUMAN 등이 알려진 클라우드 IP 요청을 제한하거나 차단하는 환경에서, 유료 주거 고객의 IP로 대상 사이트에 도달하는 우회 수단
• 연결 TV는 배터리 제약이 없고 항상 Wi-Fi에 연결되며 대기 상태로 24/7 동작해, 휴대폰보다 상시성과 방치 가능성이 큰 프록시 조건
• iOS SDK는 인증 없는 설정 엔드포인트에서 유휴 기준·대역폭 한도·파트너 목록을 받고, WebSocket 피어 터널을 열어 기기 상태 텔레메트리와 cmd_tun 스크래핑 작업을 처리
• 방어는 proxyjs.*와 clientsdk.* DNS 차단, SNI 필터링, TLS 인증서 지문 탐지, MDM 앱 바이너리 스캔이 중심이며, iOS의 use_netifs 는 VPN 기반 가시성을 우회하는 제약

개요

• AI 역량 향상을 위한 데이터센터 건설에 대한 커뮤니티 차원의 반대와 별개로, 가정 안의 기기가 AI 학습을 위한 분산 데이터 수집에 사용될 수 있는 구조
• Bright Data는 고객이 웹 스크래핑 트래픽을 라우팅하는 400M+ 가정용 IP 주소의 주거용 프록시 네트워크 접근권을 판매하며, 공급원은 소비자 앱에 삽입되는 SDK
• 해당 SDK는 사용자 동의 아래 휴대폰이나 스마트 TV를 출구 노드로 전환하며, 분석 대상은 SDK 동작 방식, 배포 플랫폼, 인터넷 연결 TV가 AI 모델용 웹 스크래핑 프록시에 적합한 이유

지금 중요한 이유

• AI 기업은 사전학습, 검색·검색증강, 에이전트 grounding, 검색 기능을 위해 웹 스크래핑 콘텐츠에 의존
• 현대 웹은 데이터센터에서 쉽게 스크래핑할 수 없는 환경이며, Cloudflare, DataDome, HUMAN 등이 알려진 클라우드 IP의 요청을 제한하거나 차단
• 대안은 Comcast나 T-Mobile 가입자 연결처럼 유료 주거 고객의 IP에서 대상 사이트로 도달하는 주거용 프록시
• 2025년 10월 Krebs 보도 인용문은 “Aisuru와 기타 출처의 프록시 과잉이 여러 AI 프로젝트와 연결된 대규모 데이터 수확 노력을 부추기고 있다”는 문장
• 2019년까지 거슬러 올라가는 학술 측정은 이런 네트워크가 압도적으로 오용된다는 결과이며, FBI도 올해 초 공식 권고를 발령
• 기존 보도 대부분은 Aisuru와 Kimwolf 같은 봇넷, PROXYLIB 같은 트로이목마화 앱, IPIDEA 같은 사전 감염 IoT 하드웨어 등 불법 주거용 프록시 공급에 집중
• 합법 공급 측면은 상대적으로 적은 검토를 받았으며, Bright Data는 자체 마케팅 기준 세계 최대 주거용 프록시 네트워크로서 파트너 앱에 삽입된 동의 SDK 기반 “150M+ IPs”를 광고

연결 TV가 이상적인 프록시인 이유

• TV는 배터리 1% 상태에 도달하지 않고, Wi-Fi 네트워크 사이를 자주 이동하지 않으며, 사용자가 잠든 동안 잠기지 않는 기기
• 일부 파트너 게시자는 개인정보 처리방침에서 Bright Data 관계를 공개하며, PlayWorks 개인정보 처리방침이 한 사례
• 개인정보 처리방침 공개는 TV에 적합한 통제 지점이 아니며, 리모컨 방향키로 법률 문서를 스크롤하기 어렵고 인앱 동의 대화창은 유료 Bright Data 고객이 사용자의 가정 인터넷을 통해 스크래핑 트래픽을 라우팅한다는 점을 전달하지 못하는 구조
• The Verge가 문서화한 Roku 앱 Petflix의 옵트인 화면은 “광고를 줄이고 무료로 즐기려면 Bright Data가 기기의 여유 리소스와 IP 주소를 가끔 사용해 인터넷의 공개 웹 데이터를 다운로드하도록 허용”한다는 문구를 사용
• Petflix 대화창은 “가끔”이라는 표현을 쓰지만, 공개 조회 가능한 SDK 설정의 max_bw_monthly_wifi: 200,000,000,000은 월 기본 Wi-Fi 예산 200GB

Bright Data가 파트너로 명명한 대상

• Bright Data는 인증 없이 누구나 가져올 수 있는 파트너 manifest 엔드포인트를 노출
• 공개 출처 기준 고신뢰 식별 항목

• desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp는 manifest에 있으나 공개 출처로 식별하기 어려운 항목
• bright_screensavers, bright_videos, brightdata는 Bright Data 자체 앱
• Bright Data 설정에 이름이 있다는 사실은 어느 시점에 통합이 있었을 가능성을 뜻하지만, 특정 게시자의 현재 배포 앱이 운영 환경에서 SDK를 탑재한다는 직접 증거는 아님
• 파트너 목록이 직접 증명하는 것은 Bright Data가 인증 없는 공개 엔드포인트에 이 명단을 배포한다는 점과, PlayWorks·CloudTV·Longvision 등 최소 세 CTV 중심 사업자가 사용자 기기를 주거용 프록시 출구 노드로 수익화했다는 점
• PlayWorks는 자체 마케팅 자료 기준 주요 TV 플랫폼과 ISP 전반의 CTV 배포, 수억 가구 규모 도달 수치를 제시

Bright Data SDK가 사용자 기기를 주거용 프록시 출구 노드로 바꾸는 방식

• Bright Data SDK는 퍼블리셔용 SDK 통합 문서와 웹용 JavaScript variant를 갖춘 공개 문서화 상용 제품
• 분석은 배포 중인 iOS 프레임워크 역공학과 30일 런타임 트래픽 계측을 기반으로 구성
• SDK는 파트너 앱 내부의 iOS 프레임워크 brdsdk.framework 형태로 배포

• 인증 없는 설정

  • SDK는 실행할 때마다 다음 요청을 호출
  • GET &ver=&uuid=sdk-ios-<32hex&gt">https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
  • 엔드포인트는 의미 있는 인증 없이 동작하며, 서버는 앱 번들 ID인 appid와 SDK 버전 문자열인 ver 두 쿼리 매개변수만 확인
  • 파트너 앱의 App Store 목록에서 찾을 수 있는 번들 ID와 SDK 버전 문자열, 임의 생성 UUID를 제공하면 실제 기기가 받는 응답과 동일한 설정을 반환
  • 응답에는 기능 플래그, 배터리 비율·CPU/메모리 상한·Wi-Fi/셀룰러 규칙 같은 유휴 감지 임계값, 국가별 대역폭 계층, 파트너 manifest가 들어있는 구조
  • 설정 안에는 기기가 트래픽 릴레이 자격을 얻는 유휴 규칙, VPN 주변으로 피어 트래픽을 라우팅하는 플래그, 플랫폼 간 설치를 하나의 신원으로 연결하는 map, 국가별 대역폭 한도가 존재

• 피어 터널

  • 설정을 가져온 뒤 SDK는 다음 주소로 지속 WebSocket을 개설
  • wss://proxyjs.brdtnet.com:443
  • 이 호스트명은 작성 시점 기준 AWS Global Accelerator IP 3.33.193.183, 15.197.193.114로 해석
  • TLS 인증서는 CN=*.luminatinet.com이며, Luminati Networks는 Bright Data의 2018년 이전 회사명
  • 2018년 리브랜딩 이후에도 활성 SDK 인프라는 legacy 인증서를 사용하며, luminatinet.com 또는 brdtnet.com 트래픽은 고객 측 Bright Data 사용이 아니라 피어 터널 plane 식별 단서
  • 현재 고객 대상 프록시 서비스는 brightdata.com 브랜드 도메인에서 동작하므로, 네트워크의 luminatinet.com·brdtnet.com 트래픽은 피어 터널 plane
  • 서버는 자신을 uWebSockets: 20으로 식별
  • 피어 엔드포인트는 업그레이드에 인증을 요구하지 않으며, TLS가 유효한 WebSocket 업그레이드를 받아들인 뒤 클라이언트의 공개 IP를 되돌려주는 애플리케이션 계층 프레임을 즉시 전송
  • 핸드셰이크 흐름
  • 1. 서버 → 클라이언트 tunnel_init: 세션을 만들고 클라이언트 공개 IP를 반환
  • 2. 서버 → 클라이언트 cid_set: <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> 형식의 세션 추적 식별자를 할당하며, 실제 기기 텔레메트리의 cid 필드와 일치 확인
  • 3. 서버 → 클라이언트 status_get: 기기의 유휴 상태, 배터리, 네트워크 유형, 사용 가능 대역폭을 폴링하고, 기기는 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 등 지속 텔레메트리로 응답
  • 4. 핸드셰이크 완료 뒤 기기가 유리한 상태를 보고하면 서버의 작업 매칭 계층이 cmd_tun 프레임을 푸시할 수 있으며, SDK는 이를 사용자의 주거용 IP를 출발지로 하는 제3자 사이트 HTTP 요청으로 실행
  • WebSocket의 모든 프레임은 고정 envelope를 가진 plain JSON
  • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
  • 바이너리에서 추출하고 실제 통신에서 확인한 명령어
  • | 방향 | cmd | 목적 |
  • |---|---|---|
  • | Server → Client | tunnel_init | 세션 개설, 공개 IP echo |
  • | Server → Client | cid_set | 세션 식별자 할당 |
  • | Server → Client | status_get | 기기 유휴·배터리·대역폭 폴링 |
  • | Server → Client | cmd_tun / tun | 스크래핑 작업 전달 |
  • | Server → Client | dns | 대상 DNS 해석 요청 |
  • | Server → Client | consent | 동의 상태 요청 |
  • | Client → Server | status_send | 기기 상태 주기 heartbeat |
  • | Client → Server | tun_report / tun_ack / tun_fin | 릴레이 작업 생명주기 응답 |
  • | Client → Server | tunnel_init_decline | 세션 거절 |
  • | Client → Server | logs | 진단 로그를 서버로 전송 |
  • 메시지 서명, HMAC, 클라이언트 인증서, 기기 attestation이 없고, 실제 작업을 받는 피어를 가르는 요소는 TLS 계층과 서버의 IP 평판 필터뿐인 구조
  • 상용 악성코드 프로토콜 설계에 익숙한 독자 기준으로 전형적 C2보다 실질적으로 낮은 보안 수준

• SDK가 “유휴”로 보는 조건

  • 설정은 다른 사람의 트래픽을 릴레이할 수 있는 기기 상태 규칙을 명시
  "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 플래그 때문에 “유휴”는 사용자가 기기에서 떨어져 있다는 뜻이 아니라, CPU·메모리·배터리가 SDK 임계값 안에 있다는 뜻
  • 사용자가 통화 중이거나 화면을 적극적으로 읽는 상태도 릴레이 목적의 유휴 상태로 간주

• 플랫폼 간 신원 연결

  • 설정에는 다음 dual_pairing map이 존재
  "dual_pairing": { "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"] }
  • 이 map은 같은 브랜드의 iOS, Windows, macOS 설치를 하나의 엔터티로 묶는 서버 측 연결 구조
  • http3_enabled: true 필드는 QUIC 기반 피어 전송을 위한 플래그이며, 향후 버전은 피어 터널을 TCP/443에서 UDP/443으로 옮길 수 있음
  • TCP 연결 추적으로 WebSocket을 탐지하는 방어자는 UDP/443 이동 시 탐지 방식이 깨질 수 있음

• 검사 우회

  • SDK 설정의 use_netifs: true 플래그는 SDK 바이너리 코드가 시스템 기본 경로 대신 특정 필수 인터페이스로 NWConnection을 구성하게 만드는 조건
  • 필수 인터페이스는 Wi-Fi의 en0 또는 셀룰러의 pdp_ip0
  • iOS에서는 이 방식이 구성된 VPN의 tun0 인터페이스를 완전히 우회하며, 앱의 다른 HTTPS 트래픽이 VPN을 지나도 피어 터널은 사용자 구성 VPN을 통과하지 않음
  • 투명 TLS 가로채기 연구 환경은 SDK의 모든 HTTPS 호출을 캡처했지만, 포트 443이 명시적으로 검사기로 리디렉션됐음에도 proxyjs.brdtnet.com:443 피어 터널은 캡처하지 못한 결과
  • 우회는 Apple의 문서화된 NWParameters.requiredInterface API를 사용
  • SDK는 두 독립 검사 우회를 사용
  • Control plane: 설정 가져오기와 텔레메트리 ping은 URLSession·NSURLConnection 대신 CFNetwork의 CFHTTPMessage primitives 기반이며, 모바일 앱 보안 도구에서 흔한 URLSession 수준 계측, swizzling, network extension, URLProtocol subclass를 무력화하면서도 시스템 프록시는 존중해 TLS 가로채기 연구자에게는 가시성 유지
  • Data plane: 피어 터널은 물리 인터페이스를 필수 인터페이스로 설정한 NWConnection 기반이며, VPN을 무력화하고 스크래핑이 주거용 IP에서 실행되도록 보장
  • MDM, 기업 VPN 기반 트래픽 검사, 홈 라우터 자녀 보호를 쓰는 보안팀에게 가장 민감한 채널은 가시성 계층을 우회하도록 설계된 상태

국가별 계층

• 설정에는 국가별 대역폭 임계값 존재

• Uzbekistan과 Oman 기기는 배터리 1%까지 릴레이가 허용되며, 일일 한도는 기본값의 20배, 월간 한도는 기본값의 60배
• Qatar와 UAE 기기는 기본값보다 낮은 한도로 제한
• 국가별 계층이 이렇게 구성된 이유는 확정 불가이며, 추측만 가능
• 전 세계 기본 허용량도 사용자 가정 인터넷을 통해 매월 다른 사람의 트래픽 500MB를 허용

테스트 설정과 방법론

• 30일 동안 동의 설치된 파트너 앱을 실행한 iOS 기기에서 TLS 가로채기 프록시 캡처를 수행했으며, 예시 앱은 Bright SDK를 내장한 XYO COIN 포함
• brdsdk.framework version 1.532.120, iOS arm64 바이너리에 대한 정적 분석 수행
• Bright Data의 특정 호스트명, 인증서 지문, TLS 인프라는 같은 요청을 수행하는 누구나 공개 관찰 가능
• 연구 플릿이나 연구 클라이언트의 세션별 식별 데이터는 문서에 없음

타임라인

• 2026년 5월 11일 privacy@brightdata.com으로 게시 예정 알림 이메일 발송
• 게시 시점까지 해당 알림에 대한 응답 없음

방어 접근법

• 트래픽은 네트워크 경계에서 명확한 fingerprint를 남기고, SDK는 앱 바이너리에 식별 가능한 심볼을 남기는 구조
• 접근법 1, DNS 차단은 네트워크를 통해 라우팅되는 기기에 간단하고 효과적인 방식
  • proxyjs.brdtnet.com
  • proxyjs.luminatinet.com
  • proxyjs.bright-sdk.com
  • clientsdk.bright-sdk.com
  • clientsdk.brdtnet.com
• proxyjs.* 차단은 피어 터널을 중단시키며, 다른 도메인에서 동작하는 Bright Data 고객 대상 프록시 서비스를 합법적으로 쓰는 고객에게는 영향 없음
• 접근법 2, TLS SNI 필터링은 server_name이 *.brdtnet.com, *.luminatinet.com, *.luminati.io와 일치하는 TLS 핸드셰이크를 차단하거나 경고하는 방식
• SNI 필터링은 TLS 검사 없이 네트워크 경계에서 동작
• 접근법 3, TLS 인증서 지문 탐지는 다음 지문 기반 차단 또는 경고
  • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
  • .luminatinet.com → SHA256 5028612e625befea…
• 인증서 지문은 Sectigo 인증서 교체 전까지 안정적이며, 현재 인증서는 2026년 중반까지 유효
• use_netifs 관련 제약 때문에 세 계층은 모두 트래픽이 네트워크 경계를 통과할 때만 동작
• iOS 기기가 셀룰러를 사용할 때 SDK의 use_netifs 바인딩은 피어 트래픽이 기업 Wi-Fi를 완전히 우회하게 만드는 조건
• 관리형 기기 fleet의 보완 통제는 MDM 기반 앱 바이너리 스캔이며, 설치 앱에서 Swift 심볼 BrdWebSocketFacade와 BrdNetwork.DNSResolver를 검색하고 해당 심볼이 있는 앱을 회사 지급 기기에서 금지하는 방식
• 특정 스마트 TV나 모바일 앱이 우려되는 가정 사용자는 라우터 DNS 설정에서 위 호스트명을 차단하는 방식 사용 가능
• 차단 도구 예시는 Pi-hole, NextDNS, Cloudflare Gateway, ISP의 동등 기능