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

(blog.includesecurity.com)

소비자 앱에 삽입되는 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 / CTV
전원	하루 대부분 배터리 사용	항상 전원 연결
네트워크	Wi-Fi + 셀룰러	항상 Wi-Fi, 고속
가동 시간	간헐적	대기 상태에서 24/7
대역폭 한도	낮음, 셀룰러 제한	사실상 무제한
사용자 주의	적극 사용	자주 방치
동의 UI	휴대폰 화면 텍스트	TV 리모컨 방향키로 탐색하는 텍스트
기업·가족 감독	MDM, 모바일 EDR 등 더 높음	사실상 없음

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 엔드포인트를 노출
공개 출처 기준 고신뢰 식별 항목

Partner ID	Entity	규모
`playworks_digital`	PlayWorks Digital Ltd	CTV 게임 타이틀 400+개, Comcast·Sky·Cox·LG·Samsung·Vizio·Roku를 통한 TV 가구 약 250M 도달
`cloudtv`	CloudTV	TV 브랜드 125+개와 OEM 15+곳 전반에 통합
`longvision_media_hong_kong_co_limited`	Longvision Media HK (LongTV)	홍콩·말레이시아 전역 OTT 사용자 5M
`viber_media_s_r_l`	Viber Media S.à r.l. (Rakuten)	Viber 메신저 월간 사용자 250M–820M
`supercent_inc`	Supercent	2023년 다운로드 기준 한국 모바일 퍼블리셔 1위
`moonfrog_labs_private_limited`	Moonfrog Labs	Teen Patti Gold 단독 약 10M MAU, 90M달러에 인수
`hola_networks`	Hola Networks	Bright Data의 계보상 모회사이며, Hola의 과거 마케팅 기준 정점 사용자 수는 수천만에서 약 100M+ 범위

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 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를 반환
- 1. 서버 → 클라이언트 cid_set: <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> 형식의 세션 추적 식별자를 할당하며, 실제 기기 텔레메트리의 cid 필드와 일치 확인
- 1. 서버 → 클라이언트 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 등 지속 텔레메트리로 응답
- 1. 핸드셰이크 완료 뒤 기기가 유리한 상태를 보고하면 서버의 작업 매칭 계층이 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	1%	1GB	30GB
Oman	1%	1GB	30GB
Qatar	20%	40MB	250MB
UAE	20%	40MB	250MB
default, worldwide	20%	50MB	500MB

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의 동등 기능

GN⁺ 1달전 [-]

Hacker News 의견들

설정을 가져온 뒤 SDK가 wss://proxyjs.brdtnet.com:443로 상시 WebSocket을 열고, 이 호스트명이 AWS Global Accelerator IP로 해석됨
스크래퍼와 스크래핑당하는 웹사이트가 둘 다 AWS에서 호스팅될 가능성이 큰데, 서로 아닌 척하며 정교한 고양이와 쥐 게임을 하는 아이러니가 있음
- Cloudflare는 DDoS 제어 패널에도 DDoS 방어 서비스를 팔고 있음
- Bright Data는 AWS Marketplace에서도 제품으로 올라와 있음
  https://aws.amazon.com/marketplace/seller-profile?id=bf9b432...
- 바로 DNS 차단 목록에 추가함
- 미국 정부가 제대로 규제하지 않는 상업 기업을 필요로 하고, 그 기업들이 프라이버시 침해를 합법적 수단처럼 제공하게 만들어 정부가 손을 씻는 구조와 비슷함
어떤 스마트 기기도 와이파이에 연결하지 않음. 연결 없이는 동작하지 않는다면 원하지 않음
TV는 그냥 디스플레이 장치로만 쓰고, HDMI 입력만 있으면 충분함
- 출고 이후 인터넷과 한 번도 통신하지 않은 스마트 TV가 있지만, 꽤 불안정한 균형이라고 느낌
  손님이 HDMI 화면 위에 몇 초 뜨는 “Services unavailable, press [menu] to troubleshoot” 토스트를 보고 도와주려는 마음으로 연결해버릴까 봐 걱정됨. 그러면 4~5년치 펌웨어 업데이트가 한 번에 들어오고, HDMI 피드에서 어떻게든 추출해 저장해둔 반십 년치 시청 데이터가 이 순간을 위해 전송되고, 광고가 사방에 뜰 것 같음
  당장 일어나지 않더라도 OS 깊숙한 곳에 makeEverythingWorse 같은 플래그가 있다가, The Beast가 조금 더 높은 패치 번호 냄새를 맡는 펨토초에 켜질 것 같음. 결국 Samsung의 누군가에게 내가 좋아하는 프로그램이 HDMI2라고 알려주는 유일한 목적을 달성한 뒤 망가진 상태가 될 뿐임
  어머니 TV에서도 그 벼랑 끝에서 물러나게 한 적이 있어 걱정할 만하다고 봄. 텅 빈 TV 홈 화면과 줄 그어진 전파탑 아이콘이 “우리도 Disney+와 CraveTV가 있어요… [menu]를 누르세요… 아들이 커피 테이블에 붙여둔 메모는 신경 쓰지 마세요”라고 유혹하는 셈임
- 괜찮음. Amazon Sidewalk 같은 기술과 싸고 가벼운 4G/5G 모듈이 있으면 이제 누구도 연결 허락을 구할 필요가 없음
  오래된 기기를 쓸 수도 있겠지만, 뒤처지고 싶지는 않지 않나. 디지털 멍에를 그냥 받아들이지 않으면 주변 사람들이 가난하거나 C.H.U.D.일지도 모른다고 생각할 것임
- 이 원칙은 이론적으로 이해하지만, TV에서 Netflix나 YouTube 같은 걸 보고 싶은 현대 생활에서 실제로 어떻게 굴러가는지는 잘 모르겠음
  TV일 수도 있고 Android 박스일 수도 있지만, 결국 어딘가에서는 제3자와 그 위에서 다른 제3자 앱을 실행할 수 있는 소프트웨어를 신뢰하게 됨. 대안은 로컬 Jellyfin 서버인데, 가족이 보고 싶어 하는 콘텐츠를 넣으려면 매우 높은 확률로 법을 어겨야 함
  개인적으로는 집에 TV가 아예 없으면 좋겠지만, 가족을 설득하기가 쉽지 않음 ;-)
- 내 TCL TV는 동의할 Google 정책을 읽으려면 먼저 연결해야 함. 연결하지 않으면 읽지 않은 정책에 동의하는 꼴임
  다행히 연결성이 없으면 이로 인한 피해 범위는 사실상 없음
- 답답하게도 TV를 네트워크에 연결해야 얻을 수 있는 일부 기능은 원함. 특히 TV 전원 켜기나 입력 선택 같은 걸 TV가 노출하는 API로 제어하는 기능임
  외부 인터넷 접근이 막힌 VLAN에 넣으면 관리 가능하지만, 그렇게까지 해야 한다는 사실 자체가 정말 성가심
원칙적으로 로컬 네트워크에서 TV를 차단하는 건 좋음. 하지만 Amazon Fire 기기가 한동안 Sidewalk를 이용해 본진으로 가는 경로를 만들지 않았나?
이웃의 Ring 초인종이 기본 설정만 유지하고 있어도 충분했을 것임
SDK 설정에 use_netifs: true 플래그가 들어 있고, 이 플래그가 SDK 바이너리에서 NWConnection을 만들 때 시스템 기본 경로 대신 특정 필수 인터페이스인 en0(와이파이) 또는 pdp_ip0(셀룰러)을 지정하게 함
iOS에서는 이 때문에 설정된 VPN의 tun0 인터페이스를 완전히 우회함. 앱의 나머지 HTTPS 트래픽이 VPN을 지나가더라도 피어 터널은 사용자 설정 VPN을 지나가지 않음
이 API의 정당한 사용 사례가 뭘까? 앱이 사용자가 설정한 VPN을 우회하도록 허용돼야 하는 경우가 언제이고 왜 있는가?
- 정당한 사용 사례라면, 그 앱이 VPN을 제공하는 애플리케이션이거나 전 세계적으로 도달 가능한 대상이 아니라 로컬에 가까운 네트워크의 무언가와 통신하도록 만든 앱일 때임
- 전체 터널링이 일시적으로 동작하지 않을 때는 분할 터널링으로 VPN 때문에 생긴 문제를 우회할 수 있음
  하지만 앱이 네트워크 경계 같은 걸 우회해서는 안 된다고 봄
순진한 질문인데, 내 기기들—대부분 iOS—이나 홈 네트워크에서 이런 걸 감지하는 방법을 배우려면 뭘 검색해야 할까?
내 기기에서 이 SDK가 활성화된 앱을 찾아 제거하고 싶음
- 더 나은 자료가 있을 수도 있지만, Mac도 있다면 이 글이 첫눈에는 괜찮아 보였음
  https://www.thequantizer.com/tutorials/wireshark-iphone-traf...
  개인적으로 이런 추적을 해본 지는 좀 됐지만, Wireshark는 쓰기 매우 쉬웠고 네트워크가 노출되면 온라인에 참고할 정보도 많음
  VPN을 우회한다는 점이 특히 끔찍했고, 전체가 다 그렇다고 봄. 개인적으로는 서비스 약관에 들어갈 수 있는 양에 제한이 있으면 좋겠음. 이제 아무도 그렇게 많은 글을 읽고 싶어 하지 않음
제안된 완화책들이 약해 보임
DNS 차단과 SNI 필터링은 이 이슈가 충분히 주목받으면 Bright Data가 엔드포인트를 순환시킬 것으로 예상됨. SDK를 포함한 모든 앱이 따라잡는 데 시간이 걸리겠지만, 영리하다면 SDK가 현재 엔드포인트에 장기간 접근하지 못할 때 시도할 백업 명령·제어 연결을 이미 갖고 있을 수도 있음
TLS 지문은 SDK가 고정하지 않는 한 계속 바꾸기 가장 싼 방법임
MDM 솔루션은 개인 사용자에게 거의 접근 불가능하고, SDK 이름이 얼마나 안정적이라 의존할 수 있는지도 불분명함
더 나은 접근법이 있다는 뜻은 아님. 이런 동작은 Apple과 Google 쪽에서 명시적으로 금지하고, 게시자 계정을 즉시 종료해야 할 것 같음
내 방화벽이 외부 세계 접근을 막으면 안 됨. 다만 Home Assistant가 제어하는 것은 허용함
- 많은 스마트 TV는 광고를 내장하고 있음. 중고 Sony Bravia를 샀다가 짜증 나는 사흘 만에 길가에 내놓았음
  부팅 루프가 걸리고 UI 입력 지연이 3초쯤 됐기 때문임. 네트워크에 연결한 적도 없는데, 친절하게도 TV 제조 시점인 약 10년 전에 개봉하던 Sony 스튜디오 영화 광고를 보여줬음
방금 확인해보니 전체 네트워크에 AdGuard를 쓰고 있음. TV에서는 요청의 80%가 차단되고, 전체 네트워크에서는 약 50%가 차단됨. 미친 수준임
이런 종류의 프록시가 불법이 아니라면, 적어도 불법이어야 한다고 봄. 인터넷 라우팅과 IP 주소 임대 및 소유권에 대한 기본 가정을 우회하는 경계에 있다고 말하는 것조차, Bright Data가 결제 가능한 제품으로 포장해낸 것에 비하면 약한 표현임
“여러분은 Bright Data가 가끔 여러분 기기의 여유 리소스와 _IP 주소를 사용해 인터넷에서 공개 웹 데이터를 다운로드_하도록 허용합니다”라는 문구가 있음
최종 사용자에게 오해를 부르는 부분은 “공개 웹 데이터를 다운로드”라는 표현임. 데이터가 공개라면 왜 Bright Data가 직접 다운로드하지 못하나? 아마 상대편이 원하지 않기 때문임. 이 제품은 돈은 있지만 인터넷에서 정당한 이유로 불리한 위치에 있는 누군가를 대신해, Bright Data가 “공개” 데이터 제공자의 원치 않는 속성을 우회하도록 사용자가 돕게 만드는 것임
완전히 개탄스럽지만, 이 방향으로 흘러가는 걸 알고 있어서 솔직히 놀랍지도 않고 걱정도 별로 안 됨. 사람들은 오래전부터 지갑으로 투표해왔음. 여기서 프록시로 쓰이는 건 프라이버시 의식이 높은 Joe the Hacker가 아니라, 하루 일과 끝에 오락을 원하는 우리 부모님과 수백만 명, 그리고 어린 자녀를 둔 부모들임
날이 갈수록 어두운 인터넷 이론이 더 그럴듯해 보이고, 솔직히 그쪽으로 가도 괜찮다고 느낌. 인터넷은 어떤 라우팅이든 홉마다 키가 필요한 봉건적 인터네트워크로 붕괴할 것이고, 그래야 실제 사람들—그리고 솔직히 에이전트들—이 지금 적극적으로 우회되고 있는 신뢰를 어느 정도 유지할 수 있음
- 완전히 합법이고, 말한 IP 라우팅과 주소 소유권에 관한 법은 존재하지 않음
여기서 보이는 문제 중 하나는 Tor 출구 노드를 운영할 때와 같은 문제임. 악의적인 사용자가 자기 위치를 숨기는 데 쓸 수 있음
실제 범인은 당신 TV를 프록시로 써서 아동 성착취물을 거래하는 사람인데, 경찰이 당신이 그걸 유통한다고 판단해 집에 찾아오는 상황을 상상해보면 됨
- 모든 것이 사용자에게 적대적으로 변해가는 게 정말 싫음. 거의 모든 것의 전문가가 되어야 하고, 기존 가정을 뒤엎는 중대한 변화가 혹시 생길까 봐 뉴스를 계속 추적해야 함
  그리고 어떻게든 놓쳐서 불평하면, 방어자들이 우르르 나와 옹호하거나, 논점을 돌리거나, 대화를 흐트러뜨림
  그나마 좋은 소식이 있다면 이런 피로감이 일반 사람들에게도 닿고 있다는 점임. 직장 동료가 아이들 제한과 한도를 제대로 적용하려면 자신이 완전한 와이파이/인터넷 관리자가 되어야 한다고 불평했음
  그냥 답답해서 하는 말임. 여기서 적절한 해결책이 뭔지 아직 잘 모르겠음
- Bright Data 같은 그룹은 고객 확인 절차를 꽤 잘 갖추고 있음. 경찰 방문으로 한바탕 겁을 먹은 뒤에는 실제 가해자가 감옥에 갈 것임

답변달기

GN⁺ 1달전 [-]

Lobste.rs 의견들

이 프로토콜을 말하면서 모든 요청에 무작위로 생성한 쓰레기 데이터를 자발적으로 내주는 역방향 허니팟을 만들면, 남는 토큰이 있는 누군가에게 재미있는 바이브 코딩 프로젝트가 될 수도 있겠다
- 굳이 프로토콜을 구현할 필요는 없어 보임. 로그를 보면 이런 주거용 프록시 중 상당수가 자신을 숨기는 데 완전히 실패해서, 그냥 손쉽게 쓰레기 데이터를 내보낼 수 있음
  바이브 코딩도 필요 없고, 이미 이런 일을 할 수 있는 도구가 수십 개는 있음. 그중 상당수는 1년 넘게 이런 프록시에 끝없는 쓰레기 데이터를 잘 제공해 왔음
왜 TV든 다른 가전이든 인터넷에 연결하는지 전혀 이해가 안 됨. 그렇게 해야 할 좋은 이유가 없음
- 사람들은 TV로 스트리밍 서비스를 봄. TV를 인터넷에 연결하는 게 그걸 하는 가장 쉬운 방법임

답변달기

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

개요

지금 중요한 이유

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

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

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

인증 없는 설정

피어 터널

SDK가 “유휴”로 보는 조건

플랫폼 간 신원 연결

검사 우회

국가별 계층

테스트 설정과 방법론

타임라인

방어 접근법

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들

Lobste.rs 의견들