# 您客厅里的智能电视是 AIScraping 经济中的一个节点 - 来源：Hacker News 热门（buzzing.cc 中文翻译） - 作者：nikcub - 发布时间：2026-06-06 21:47 - AIHOT 分数：70 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmq2exy4s00scsl78ze6yib54 - 原文链接：https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy ## 精选理由 这篇把智能电视变成 AI 数据抓取节点的黑箱拆开了，逆向工程细节让人后背发凉，建议所有用智能电视或做 AI 数据的人都读一遍。 ## AI 摘要 智能电视被描述为 AI 抓取经济中的节点，客厅设备可能被用于大规模数据采集网络。该观点来自一篇安全博客，揭示了家庭联网设备在 AI 训练数据供应链中的潜在角色。 ## 正文 Include Security 的工作让我们日复一日地与 AI 打交道（攻击它、使用它、训练它，等等）。 我们都知道，最近为提升 AI 能力而建设的数据中心正面临社区层面的反对。但你可能不知道的是，那些可能正在利用你家中的设备进行的分布式 AI 训练努力。 在这篇文章中，我们将探讨 Bright Data 这家公司如何利用其住宅代理网络，帮助现代 AI 模型从互联网抓取训练数据。Bright Data 是一家数据采集公司，它出售其号称全球最大住宅代理网络的访问权限——该网络拥有超过 4 亿个家庭 IP 地址，客户可通过这些 IP 路由网络爬虫流量。该网络的后端支持来自一个 SDK：这是一种嵌入在消费类应用中的软件，在用户同意后，会将用户的手机或智能电视变成这些出口节点之一。我们将为你——普通用户——记录关于这家公司的 SDK 在你的手机、智能电视等系统上做了些什么。我们将探究他们的 SDK 如何工作、哪些平台已搭载该 SDK，以及为什么你联网的电视会成为 AI 模型从互联网抓取数据训练时的终极代理。 为何此事现在值得关注 AI 公司依赖网络抓取的内容：用于预训练、检索、智能体 grounding 以及搜索。但现代互联网无法从数据中心直接抓取。Cloudflare、DataDome、HUMAN 等公司会限制或屏蔽来自已知云 IP 的请求。 变通方案就是住宅代理。通过 Comcast 或 T-Mobile 用户连接路由的抓取任务，会从一个属于付费住宅用户的 IP 地址到达目标网站。Krebs 在 2025 年 10 月的报道中指出，“来自 Aisuru 及其他来源的大量代理正在助推与各种 AI 项目相关的大规模数据采集活动。”可追溯至 2019 年的学术测量显示，这些网络被严重滥用。FBI 已于今年早些时候发布了正式咨询。 现有的大部分报道都聚焦于非法住宅代理的供应端：僵尸网络（如 Aisuru、Kimwolf）、木马化的应用程序（HUMAN Security 披露的 PROXYLIB）、预感染恶意软件的物联网硬件（Google/Mandiant 的 IPIDEA 打击行动）。这些都是恶意行为者。 而另一方面，合法的供应端受到的审查则要少得多。如今，Bright Data 自称是全球最大的住宅代理网络，宣称拥有“1.5 亿以上的 IP 地址”，这些 IP 来源于嵌入到合作伙伴应用中的“同意 SDK”。接下来，我们来深入了解该 SDK 的工作原理以及它所运行的平台，从而理解为什么联网电视会成为终极住宅代理。 为什么联网电视（CTV）是理想的代理 联网电视，也就是智能电视，是一种近乎完美的住宅代理。与手机相比： 因素手机智能电视 / CTV 电源大部分时间靠电池始终插电 网络WiFi + 蜂窝网络始终 WiFi，高速 开机时长间歇性全天候待机 带宽上限低（受蜂窝套餐限制）实际上不受限 用户注意力主动使用通常无人值守 同意界面手机屏幕上的文字通过电视遥控器方向键导航的文字 公司/家庭监管较高（MDM、移动端 EDR）几乎为零 电视永远不会电量降到 1%，不会在 WiFi 网络之间切换，也不会在用户睡着时被锁定。我们发现，发布商在其隐私政策中披露了与 Bright Data 的关系，PlayWorks 就是一个例子。从消费者的角度来看，这些通知很容易被忽略，因为用电视遥控器的方向键来翻阅法律文件非常困难。 Petflix 是一个 Roku 应用，由 The Verge 报道，是一个典型案例。其选择加入的界面写道：“为了免费享受 Petflix 并减少广告，您允许 Bright Data 偶尔使用您设备的空闲资源和 IP 地址，从互联网上下载公共网络数据。Bright Data 仅会将您的 IP 地址用于经批准的业务相关用途。除您的 IP 地址外，不会访问或收集您的任何个人信息。句号。”Petflix 的对话窗口中写着“偶尔”。该 SDK 的公开可查询配置中设置了`max_bw_monthly_wifi: 200,000,000,000 bytes`——每月默认最高 WiFi 流量限制为 200 GB。 Bright Data 声称的合作伙伴 Bright Data 暴露了一个合作伙伴清单端点。该端点无需身份验证，任何人都可以获取。以下是我能够从公开来源高置信度识别的清单中的名称： 合作伙伴 ID（来自配置）实体规模 playworks_digitalPlayWorks Digital Ltd400 多款 CTV 游戏；通过 Comcast、Sky、Cox、LG、Samsung、Vizio、Roku 覆盖约 2.5 亿电视家庭 cloudtvCloudTV已集成到 125 多个电视品牌和 15 多个 OEM 厂商中 longvision_media_hong_kong_co_limitedLongvision Media HK (LongTV)在香港和马来西亚拥有 500 万 OTT 用户 viber_media_s_r_lViber Media S.à r.l. (Rakuten)Viber 即时通讯月活跃用户 2.5 亿至 8.2 亿 supercent_incSupercent (韩国)2023 年韩国移动发行商下载量排名第一 moonfrog_labs_private_limitedMoonfrog Labs (Stillfront 子公司)仅 Teen Patti Gold 一款游戏就有约 1000 万月活用户；以 9000 万美元收购 hola_networksHola NetworksBright Data 的集团母公司；根据 Hola 自身历史营销资料，其用户群在高峰期据称达到数千万至超过 1 亿 其他名称（desoline、free_time、ott_studio、global_microtrading、m_m_media、easystaff_lp）也存在，但从公开来源较难识别。bright_screensavers、bright_videos 和 brightdata 是 Bright Data 自己的应用。 关于合作伙伴清单能证明什么的说明：出现在 Bright Data 的配置中意味着在某个时间点可能曾存在集成。但这本身并不能证明某个特定发行商当前发布的应用程序在生产中包含了该 SDK。对于任何列出的发行商，都需要对每个应用进行逐一验证。 合作伙伴清单直接能证明的是： Bright Data 通过未经认证的公共端点提供这份名单。 至少有三家专注于 CTV 的实体（PlayWorks、CloudTV、Longvision）将用户的设备作为住宅代理出口节点进行变现。尤其是 PlayWorks，根据其自身的营销资料，它通过主要电视平台和 ISP 分发 CTV，覆盖数亿家庭。 Bright Data SDK 如何将用户的设备变成住宅代理出口节点？ Bright Data SDK是一款公开文档化的商业产品，通过Bright Data的SDK集成文档（包含用于网页的JavaScript版本）提供给发布商。下文基于这一公开信息，并结合对已发布iOS框架的反向工程以及对其运行时流量30天的监测结果进行阐述。 该SDK以iOS框架（brdsdk.framework）的形式内嵌在合作伙伴应用中。我对二进制文件进行了反向工程，并从一组运行该SDK（安装在已获得用户同意的合作伙伴应用内）的研究设备上捕获了30天的流量。 无身份验证的配置 每次启动时，SDK会调用： GET ?appid=&ver=&uuid=sdk-ios-<32hex> 该端点实际上没有任何有意义的身份验证。服务器仅通过两个查询参数进行访问控制：appid（应用包标识符，可在合作伙伴应用在App Store的页面中找到）和ver（SDK版本字符串）。提供这些参数以及任意随机生成的UUID，服务器就会返回与真实设备相同的响应：功能开关、空闲检测阈值（电池百分比、CPU/内存上限、WiFi vs 蜂窝网络规则）、各国家/地区的带宽等级，以及我上面展示的合作伙伴清单。每一个分支都值得单独审视：决定设备何时可以参与中继的空闲规则、将对等流量绕过VPN的路由标记、将跨平台安装整合为单一身份的地图，以及各国家/地区的带宽上限。 对等隧道 获取配置后，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 基础设施仍在使用旧证书运行，这是一个有用的检测线索：目前客户端的代理服务位于 brightdata.com 品牌域名下，因此你网络中任何 luminatinet.com / brdtnet.com 的流量都属于对等隧道层面，而非客户端的 Bright Data 使用行为。该服务器自我标识为 uWebSockets: 20。 对等端点无需身份验证即可升级连接。服务器接受任何通过 TLS 验证的 WebSocket 升级请求，并立即向连接客户端推送一个应用层帧，其中回显了客户端的公网 IP。随后，握手流程展开： 服务器 → 客户端：tunnel_init 建立会话，返回客户端的公网 IP。 服务器 → 客户端：cid_set 服务器为客户端分配一个会话跟踪标识符，格式为 -/lscp443__。我们确认此格式与 SDK 从真实设备捕获的遥测流量中出现的 cid 字段一致。 服务器 → 客户端：status_get 服务器轮询设备的空闲状态、电池、网络类型和可用带宽。设备以持续遥测数据流响应：idle（空闲）、wifi_connected（WiFi 已连接）、mobile_connected（移动网络已连接）、mobile_type（LTE/5G）、roaming（漫游）、battery_level（电池电量）、using_battery（正在使用电池）、screen_on（屏幕点亮）、on_call（通话中）、cpu_usage（CPU 使用率）、mem_usage（内存使用率）、raw_bw（原始带宽）、bw（带宽）、ipv6_supported（支持 IPv6）、appid（宿主应用）、sdk_version（SDK 版本）、platform（平台）以及分配的 cid。这是一组持续向第三方传输的真实物理设备状态数据流，通过一个内容由宿主应用发布者选择的同意对话框进行传输。 握手完成。一旦设备报告了有利的状态，服务器的任务匹配层即可自由推送 cmd_tun 帧：这些是独立的抓取作业指令，SDK 将其作为 HTTP 请求针对第三方网站执行，并使用用户的住宅 IP 作为源地址。 WebSocket 上的每一个帧都是带有固定信封的纯 JSON 格式。 {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": , "cookie": ,"err_code": 0, "msg": { ...payload... }} 从二进制文件中提取并在线路上验证的完整命令词汇表： 方向命令（cmd）用途 服务器 → 客户端tunnel_init打开会话，回显公网 IP 服务器 → 客户端cid_set分配会话标识符 服务器 → 客户端status_get轮询设备空闲/电池/带宽状态 服务器 → 客户端cmd_tun / tun分发一个爬取任务 服务器 → 客户端dns请求对目标进行 DNS 解析 服务器 → 客户端consent请求同意状态 客户端 → 服务器status_send携带设备状态的周期性心跳 客户端 → 服务器tun_report / tun_ack / tun_fin中继任务生命周期响应 客户端 → 服务器tunnel_init_decline拒绝会话 客户端 → 服务器logs将诊断日志发送到服务器 对等 WebSocket 连接使用 TLS，但不包含消息签名、HMAC、客户端证书或设备证明。服务器的 IP 信誉过滤器决定哪些对等方接收爬取任务。 当 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 映射： "dual_pairing": { "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]} 这是一个服务器端映射，将同一品牌的用户在 iOS、Windows 和 macOS 上的安装归并为一个实体。它是一种跨平台的设备身份拼接，记录在公开的配置文件中。还有一个前瞻性字段：http3_enabled: true。该 SDK 已经包含了用于基于 QUIC 的端到端传输的标志。未来版本可能会将端到端隧道从 TCP/443 迁移到 UDP/443，这将打破任何依赖 TCP 连接追踪来检测 WebSocket 的防御手段。 检测规避 该 SDK 的配置中包含一个标志“use_netifs”: true。此标志会触发 SDK 二进制中的代码，使其在构造 NWConnection 时指定特定的必需接口：en0（WiFi）或 pdp_ip0（蜂窝网络），而不是使用系统默认路由。 在 iOS 上，这完全绕过了任何已配置 VPN 的 tun0 接口。即使应用程序的其他 HTTPS 流量走 VPN，端到端隧道也不会经过用户配置的 VPN。 我们通过实证观察到了这一点。我的研究设置包括透明的 TLS 拦截。它捕获了 SDK 发出的所有 HTTPS 调用，但唯独没有捕获取道 proxyjs.brdtnet.com:443 的端到端隧道，尽管端口 443 已被明确重定向至检测器。该规避方式使用了 Apple 文档化的 NWParameters.requiredInterface API。 值得强调的是，该 SDK 使用了两种独立的检测规避手段，每种对应一个平面： 控制平面（配置获取、遥测 ping）：基于 CFNetwork 的 CFHTTPMessage 原语构建，而非 URLSession/NSURLConnection。这绕过了移动应用安全工具中常用的 URLSession 层级检测手段（方法交换、网络扩展、URLProtocol 子类），但同时仍遵循系统代理设置，因此对实施 TLS 拦截的研究人员仍然可见。 数据平面（端到端隧道）：基于 NWConnection 构建，并将 requiredInterface 设置为物理接口。这正是规避 VPN 并确保抓取操作从住宅 IP 发起的方式。 这两种选择都是合法的 Apple API。有趣的是二者的组合：数据平面对基于 VPN 的检测不可见，而控制平面对基于 URLSession 的钩子不可见。只依赖其中一种技术的研究人员只能看到 SDK 一半的行为。 地理层级 该配置针对不同国家设定了带宽阈值。其中四个国家采用了明确的非默认策略： 国家中继所需最低电量每日上限每月上限 乌兹别克斯坦1%1 GB30 GB 阿曼1%1 GB30 GB 卡塔尔20%40 MB250 MB 阿联酋20%40 MB250 MB 默认（全球范围）20%50 MB500 MB 查看配置后发现，乌兹别克斯坦和阿曼的设备在电量降至 1% 时仍可进行中继，其每日上限为默认值的 20 倍，每月上限为默认值的 60 倍。卡塔尔和阿联酋的设备则受到限制，低于默认值。我们只能推测为何如此划分等级。一种解读是刻意的市场细分——在电网供电稳定的地区放宽限制，在移动数据费用高昂的地区加以限制。全球范围内的默认配额仍然允许用户通过自家网络每月为他人转发最多 500 MB 的流量。 测试设置与方法 数据来源： 从运行已安装并经过用户同意的合作应用（包括嵌入了 Bright SDK 的 XYO COIN）的 iOS 设备上，收集了三十天经过 TLS 检测的代理捕获数据。 对 SDK 二进制文件（brdsdk.framework，版本 1.532.120，iOS arm64）进行了静态分析。 所有特定的 Bright Data 主机名、证书指纹及 TLS 基础设施信息，任何执行相同请求的观察者均可公开获取。本文档中未包含来自研究设备群或研究客户端的任何会话特定标识数据。 沟通与行动时间线 2026 年 5 月 11 日——向 privacy@brightdata.com（该邮箱地址在其法律隐私声明页面及信任与安全门户中均有引用）发送邮件通知，告知其团队本博客文章的发布。截至本文发布时，尚未收到对该通知的回复。 2026 年 6 月 5 日——博客文章发布 2026 年 6 月 8 日——收到 Bright Data 公关与通讯部门发来的邮件，包含关于本文内容的反馈意见。邮件中还附带了一份由普华永道（PwC）撰写的报告链接。根据他们提供的额外信息，IncludeSec 对博客文章做了一处适当的微小修改。 2026 年 6 月 11 日——IncludeSec 进行了额外的微小修改，使表述更加具体。 2026年6月17日——补充Bright Data公关负责人Jennifer Burns提供的回应：“Bright Data是一个基于同意的网络，每个节点都已在专用的通俗语言说明页面上明确选择加入，每个合作伙伴应用都经过强制性合规审查，每位客户都要通过实时KYC审核，我们的实践也受到独立审计师和安全公司的审查。我们有意保持可被发现性，因此也负有责任。我们想直接承认一个发现：本研究中指出的iOS VPN绕过行为是一个漏洞，且已修复。” 防御方法 该流量会在网络边界留下明显印迹，SDK也会在应用二进制文件中留下可识别的符号。以下方法可让你在网络层面或设备本身上检测并拦截对等节点隧道。按部署难度由易到难，共三种方法： 方法一：DNS拦截（简单，对走网络路由的设备有效）： proxyjs.brdtnet.comproxyjs.luminatinet.comproxyjs.bright-sdk.comclientsdk.bright-sdk.comclientsdk.brdtnet.com 拦截 proxyjs.* 即可阻断对等节点隧道，同时不会影响任何在另一域名下合法使用Bright Data面向客户代理服务的用户。 方法二：TLS SNI过滤：对 server_name 匹配 *.brdtnet.com、*.luminatinet.com 或 *.luminati.io 的TLS握手进行丢弃或告警。在网络边界生效，无需TLS检查。 方法三：TLS证书指纹： .brdtnet.com → SHA256 313ce4ec7d5a51e5… .luminatinet.com → SHA256 5028612e625befea… 在Sectigo证书轮换前保持稳定（当前证书有效期至2026年中）。 use_netifs说明：以上所有三层防护仅对跨越你网络边界的流量有效。SDK的use_netifs绑定意味着在iOS上，当设备使用蜂窝网络时，对等节点流量会完全绕过公司WiFi。对于受管设备群，补充控制手段是基于MDM的应用二进制扫描：检查已安装应用中是否存在Swift符号BrdWebSocketFacade和BrdNetwork.DNSResolver，并禁止公司配发设备上包含这些符号的应用。 对于担心特定智能电视或移动应用的家庭用户：在路由器的 DNS 设置中（Pi-hole、NextDNS、Cloudflare Gateway 或你的运营商提供的同类服务）屏蔽上述主机名即可。 这篇博客文章是与我们的特邀作者、独立安全研究员 Buchodi 合作撰写的。