你家客厅的智能电视，正给 AI 当抓数据的出口节点

概述

安全公司 IncludeSecurity 和独立研究者 Buchodi 逆向了一个嵌在消费类 App 里的软件开发包（SDK），把它的运行行为完整摊在了桌面上。这个 SDK 来自 Bright Data，一家自称运营着全球最大住宅代理网络的数据采集公司。它的角色很具体：让 AI 公司想抓的网页训练数据，能从一台普通家庭用户的网络连接里流出去，而不是从一眼就会被拦的数据中心机房里流出去。

研究者抓了 30 天的网络流量，静态分析了 iOS 端的框架二进制（brdsdk.framework，1.532.120 版），结论不靠传闻。这台设备会持续把自己的物理状态（是否空闲、电量、网络类型、CPU 内存占用）上报给第三方服务器，服务器再把一条条抓取任务下发回来，让设备用住户自己的住宅 IP 去请求别的网站。这篇调查的价值不在”曝光阴谋”，而在于它用可复现的技术证据，把”AI 的数据胃口正在反向改造消费设备”这件事钉死了：它不是趋势预测，是已经在跑的链路。

发生了什么

Bright Data 把住宅代理的”供给”外包给了一个 SDK：发行商（游戏、工具、智能电视应用的开发商）把它集成进自己的 App，在拿到用户”同意”后，把用户的手机或智能电视变成代理网络里的一个出口节点。文中给出的 Roku 应用 Petflix 是个代表案例，它的同意弹窗写着：允许 Bright Data “偶尔”使用设备的空闲资源和 IP 地址去下载公开网页数据。

研究者把”偶尔”和实际配置摆在一起对照，这是全文最有力的一处反差。SDK 那份公开可查的配置里，WiFi 下默认每月带宽预算 max_bw_monthly_wifi 是 200,000,000,000 字节，也就是 200 GB。弹窗的措辞和工程默认值之间的距离，本身就是判断材料：“偶尔”是写给人看的，200 GB 是写给机器跑的。

技术链路是这样跑起来的。SDK 每次启动都会去拉一份配置文件，请求地址是 clientsdk.bright-sdk.com/sdk_config_ios.json，带上 App 的包名（appid）和 SDK 版本号（ver）。研究者发现这个接口在任何有意义的层面上都不需要鉴权：只要给对包名和版本号，再随便编一个 UUID，服务器就会返回和真实设备一模一样的内容，包括功能开关、空闲判定阈值、分国家的带宽档位，以及一份合作发行商清单。换句话说，任何人都能读到这套机制的底牌。

拉完配置，SDK 会向 proxyjs.brdtnet.com:443 开一条常驻的 WebSocket 连接。一个细节值得记下来：这条连接的 TLS 证书通用名是 *.luminatinet.com。Luminati Networks 是 Bright Data 在 2018 年改名前的旧称，改名是公开宣布过的，但出口隧道这条链路至今还跑在旧证书上。这不是八卦，而是研究者给出的一个干净的辨识点：你网络里出现 luminatinet.com / brdtnet.com 的流量，就明确是”出口节点”这一面，而不是某个客户正常调用 Bright Data 代理服务那一面。

连接建立后是一套握手：服务器先回显设备的公网 IP、分配一个会话标识，然后开始轮询设备状态。设备则持续上报一串遥测：是否空闲、WiFi 是否连接、移动网络类型（LTE/5G）、是否漫游、电量、是否在用电池、屏幕是否亮着、是否在通话、CPU 占用、内存占用、可用带宽等等。研究者的措辞很准：这是一条把物理设备状态连续喂给第三方的数据流，而决定这条流要不要开的那个同意弹窗，文案是由集成它的发行商自己写的。状态一旦”合格”，服务器就开始下发 cmd_tun 帧，也就是一条条抓取任务，SDK 把它们当成 HTTP 请求打向第三方网站，源 IP 就是住户家里的那个住宅 IP。

研究者还点了一句行内人才会会心的话：整条 WebSocket 协议是明文 JSON，没有消息签名、没有 HMAC、没有客户端证书、没有设备认证，只靠 TLS 一层和服务器侧的 IP 信誉过滤。对于熟悉商业恶意软件协议设计的人来说，这套东西比典型的 C2（命令与控制）通道还要简陋。这句对照不是为了耸动，而是在说：决定”哪台设备该接活”的安全边界，薄到几乎只剩一层 TLS。

为何重要

把这件事放回 AI 的供应链里看，逻辑就顺了。AI 公司高度依赖从网上抓来的内容：预训练要、检索要、给智能体做事实接地要、做搜索也要。但现代的网，从数据中心里是抓不动的，Cloudflare、DataDome、HUMAN 这类防护会限速或直接拦掉已知云厂商 IP 发出的请求。绕过去的办法就是住宅代理。一条经由某个 Comcast 或 T-Mobile 用户连接发出的抓取请求，落到目标网站时，看起来就是一个正常付费住户的访问。

这就是这篇调查真正咬住的命题：AI 的数据需求正在把”监视资本主义”推进客厅。过去几年关于代理供给的报道大多盯着非法那一侧，僵尸网络、被植入木马的 App、出厂就带后门的物联网硬件。文中提到 Krebs 在 2025 年 10 月报道过，来自 Aisuru 等来源的大量代理正在喂养与多个 AI 项目相关的大规模数据采集，联邦调查局今年早些时候也发过正式预警。但拿着用户”同意”做这件事的合法那一侧，受到的审视少得多。这篇文章的贡献，是把放大镜对准了合法供给。它没有声称某家发行商今天的线上版本一定含这个 SDK（作者明确说清单只能证明”集成可能曾经存在过”，逐 App 核实是另一回事），但它实打实证明了 Bright Data 把这份合作清单放在一个不需鉴权的公开接口上，且至少 PlayWorks、CloudTV、Longvision 三家以智能电视为主的实体把用户设备当成了出口节点变现。

为什么偏偏是智能电视？文中那张手机 vs 智能电视的对照表是整个立论的支点。电视永远插着电、永远连着高速 WiFi、待机时 24 小时在线、带宽几乎无上限、还经常没人盯着，它从不会掉到 1% 电量，不会在不同 WiFi 间跳来跳去，也不会在用户睡着时被锁屏。更要命的是同意与监管这两栏：手机上还能用移动设备管理（MDM）、终端检测响应（EDR）兜一层，电视上几乎为零；手机上的同意文案是屏幕上的文字，电视上则是要靠遥控器方向键去翻的法律文档。研究者一句话戳破了关键：隐私政策披露对一台电视来说是错的控制面，没人会拿遥控器一行行去读法律条款。智能电视之所以是”理想代理”，恰恰是因为它处在消费者注意力和企业管控的双重盲区里。

还有几个配置细节，把”用户其实没在控制这件事”坐实了。空闲判定里有 ignore_screen_on: true 和 ignore_on_call: true 两个开关，意思是屏幕亮着也照样中继、用户正在打电话也照样中继。所谓”空闲”压根不是指人离开了设备，只是指 CPU、内存、电量落在 SDK 设定的阈值内。配置里还有一张 dual_pairing 映射表，把同一品牌在 iOS、Windows、macOS 上的安装拼成同一个身份，这是写在公开配置文件里的跨平台身份缝合。另一个绕过更刺眼：配置里 use_netifs: true 会让 SDK 把连接绑定到物理网卡（WiFi 的 en0 或蜂窝的 pdp_ip0），从而绕开用户配置的 VPN 隧道接口。研究者用透明 TLS 拦截做了实证：即便 443 端口已被明确重定向到拦截器，他抓到了 SDK 发出的每一个 HTTPS 调用，唯独抓不到那条通往出口隧道的连接。这意味着，用户哪怕开了 VPN 想保护自己，出口隧道这条线照样从家里的真实 IP 出去。

对建设者的影响

如果你在做依赖第三方数据的产品，这篇文章是一记供应链信任的提醒，应该当成尽职调查清单来读，而不是当新闻看完就算。

第一，数据来源的合规与伦理风险是真实的，而且会顺着供应链往下传。你买的”网页数据”或”代理服务”，其供给端很可能就是这类嵌在消费 App 里、靠遥控器方向键翻出来的”同意”撑起来的住宅出口。文中说得很克制：被列进 Bright Data 的清单只证明某个集成”可能曾经存在过”，要确认某家发行商当前线上的 App 是否真的在产带这个 SDK，必须逐 App 核实。把这条纪律照搬到你自己的采购上：别把供应商的营销话术当合规证据，要求对方说清出口流量的供给来源，并自己做 per-app 级别的核实。

第二，要预期用户对”我的设备在替 AI 偷偷采数据”产生反弹，并据此设计你自己的同意面。这件事上了 Hacker News（234 赞），说明它戳到了开发者社区的神经。Petflix 那个”偶尔”对 200 GB 默认预算的反差，正是信任崩塌的典型剧本。教训对建设者是双向的：如果你在产品里集成任何会用到用户资源、IP 或设备状态的第三方组件，“同意”必须建立在用户真能理解的控制面上。把它埋进遥控器要翻的隐私政策里，等于没有同意，一旦被逆向出来，反噬的是你的品牌而不是供应商的。

第三，这对依赖第三方数据的产品是一次供应链信任的压力测试。研究者给出的防御手段恰好也是建设者的自查工具：在网络边界上，可以直接 DNS 屏蔽或按 TLS SNI 过滤 *.brdtnet.com、*.luminatinet.com 这类域名；在托管设备上，可以用 MDM 扫描已装 App 的二进制符号（如 BrdWebSocketFacade、BrdNetwork.DNSResolver），在公司设备上禁掉含这些符号的 App。如果你管着一支设备车队或一套企业网络，这套检测今天就能落地。但要记住作者点出的那条限制：use_netifs 绑定物理网卡意味着，当设备走蜂窝网络时，出口流量会绕开公司 WiFi，所有基于网络边界的检测都只在流量过你边界时才有效，设备级的二进制扫描是必要的补充。

该忽略什么

不要把这篇文章读成”你家电视在偷拍你”或”AI 公司在你客厅装了监控”。它没说任何这类话。研究者反复强调：上报的是设备的物理状态遥测（空闲、电量、网络），抓取任务打向的是第三方公开网页，文中也明确说同意弹窗的存在和”除 IP 外不采集个人信息”是 Petflix 自己的措辞。真正的问题不是”窃听内容”，而是”同意的质量”和”设备被借用去干什么”。把它渲染成监听阴谋，反而会模糊掉真正可操作的那部分。

也不要纠结于那张分国家带宽表去做地缘解读。配置里乌兹别克斯坦和阿曼能放行到 1% 电量、日上限是默认的 20 倍，卡塔尔和阿联酋则被压到默认以下，但作者自己写得很老实：“我们只能猜测档位为何这样划”，一种读法是按电网稳定度和移动资费做市场分层。既然原作者都只给到”推测”，下游就更不该把它当成确证的结论去引申。该记住的是那个默认值：全球默认每月仍放行 500 MB 别人的流量经过你的家庭网络。这个数字本身已经够说明问题，不需要给它叠加未经证实的动机。

最后，不必为”这是不是非法”争论不休。文章的框架很清楚：它讨论的恰恰是合法供给侧，有用户同意、是公开的商业产品、用的全是苹果有文档的合规 API。值得建设者上心的，不是它合不合法，而是”合法”二字在这里被压缩到了多薄：一个遥控器翻不动的弹窗，就构成了把你家网络借给 AI 抓数据的全部授权基础。

技术要点

整条机制最值得工程师记住的，是它的双重检测规避设计，这也是研究者点明的”最有意思的产物”。SDK 把控制面和数据面拆成两套，各用一种规避。控制面（拉配置、发遥测）建在 CFNetwork 的 CFHTTPMessage 原语上，绕开了移动安全工具常用的 URLSession 级别插桩（方法替换、网络扩展、URLProtocol 子类），但仍走系统代理，因而对做 TLS 拦截的研究者可见；数据面（出口隧道）建在 NWConnection 上并绑定物理网卡，从而绕开 VPN、确保抓取一定从住宅 IP 发出。两者都是苹果有文档的合规 API，但组合起来的效果是：只用单一技术做检测的研究者，永远只能看到这个 SDK 一半的行为。配置里还埋了一个前瞻字段 http3_enabled: true，出口隧道未来可能从 TCP/443 迁到基于 QUIC 的 UDP/443，那会让所有靠 TCP 连接跟踪做检测的防御方失效。对做端侧安全或反爬的人，这是个值得提前布防的信号。

来源

1. The Smart TV in Your Living Room Is a Node in the AI Scraping Economy / blog
2. The smart TV in your living room is a node in the AI scraping economy (Hacker News) / hn

无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。