リビングのスマートTVはAIスクレイピング経済のノード

 (blog.includesecurity.com)
3 ポイント 投稿者 GN⁺ 2026-06-07 | 2件のコメント | WhatsAppで共有
  • コンシューマー向けアプリに組み込まれる Bright Data SDK は、ユーザーの同意のもとで携帯電話やスマートTVを住宅用プロキシの出口ノードに変換し、顧客のWebスクレイピングトラフィックを家庭用IP経由でルーティングする
  • 住宅用プロキシ は、Cloudflare、DataDome、HUMAN などが既知のクラウドIPからのリクエストを制限または遮断する環境で、有料の住宅契約者のIPを使って対象サイトに到達するための迂回手段
  • コネクテッドTVは、バッテリー制約がなく常時Wi-Fiに接続され、待機状態のまま24時間365日動作するため、携帯電話よりも 常時性 と 放置されやすさ の面でプロキシに適した条件を備える
  • iOS SDK は、認証のない設定エンドポイントからアイドル基準・帯域幅上限・パートナー一覧を取得し、WebSocketピアトンネル を開いてデバイス状態のテレメトリと cmd_tun スクレイピング作業を処理する
  • 防御策は proxyjs.* と clientsdk.* のDNSブロック、SNIフィルタリング、TLS証明書フィンガープリント検知、MDMによるアプリバイナリスキャンが中心であり、iOSの use_netifs はVPNベースの可視性を回避する制約となる

概要

  • AI能力向上のためのデータセンター建設に対するコミュニティレベルの反対とは別に、家庭内の機器がAI学習向けの分散データ収集に使われうる構造がある
  • Bright Data は、顧客がWebスクレイピングトラフィックをルーティングするための4億超の家庭用IPアドレスから成る住宅用プロキシネットワークへのアクセス権を販売しており、その供給源はコンシューマー向けアプリに組み込まれるSDKである
  • 当該SDKは、ユーザーの同意のもとで携帯電話やスマートTVを出口ノードに変換し、ここでの分析対象はSDKの動作方式、配布プラットフォーム、そしてインターネット接続TVがAIモデル向けWebスクレイピングプロキシに適している理由である

今重要な理由

  • AI企業は、事前学習、検索・検索拡張、エージェントのグラウンディング、検索機能のためにWebスクレイピングされたコンテンツに依存している
  • 現代のWebはデータセンターから容易にスクレイピングできる環境ではなく、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
電源 1日の大半がバッテリー駆動 常時電源接続
ネットワーク Wi-Fi + セルラー 常時Wi-Fi、高速
稼働時間 断続的 待機状態で24時間365日
帯域幅上限 低い、セルラー制限あり 実質無制限
ユーザーの注意 能動的に使用 放置されがち
同意UI 携帯画面上のテキスト TVリモコンの方向キーで移動するテキスト
企業・家族による監督 MDM、モバイルEDRなどで比較的高い 事実上ない
  • TVはバッテリー残量1%に達することがなく、Wi-Fiネットワーク間を頻繁に移動せず、ユーザーが眠っている間にもロックされない機器である
  • 一部のパートナー配信事業者はプライバシーポリシーで Bright Data との関係を開示しており、PlayWorks のプライバシーポリシー がその一例である
  • プライバシーポリシーでの開示はTVに適した統制ポイントではなく、リモコンの方向キーで法的文書をスクロールするのは難しく、アプリ内同意ダイアログも、有料の Bright Data 顧客がユーザーの家庭用インターネットを通じてスクレイピングトラフィックをルーティングすることを伝えられない構造になっている
  • The Verge が記録した Roku アプリ Petflix のオプトイン画面では、「広告を減らして無料で楽しむため、Bright Data がデバイスの余剰リソースとIPアドレスを時折使用して、インターネット上の公開Webデータをダウンロードすることを許可する」という文言が使われている
  • 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世帯約2.5億に到達
cloudtv CloudTV TVブランド125超およびOEM 15社超に統合
longvision_media_hong_kong_co_limited Longvision Media HK (LongTV) 香港・マレーシア全域でOTTユーザー500万
viber_media_s_r_l Viber Media S.à r.l. (Rakuten) Viberメッセンジャーの月間ユーザー2.5億〜8.2億
supercent_inc Supercent 2023年ダウンロード基準で韓国モバイルパブリッシャー1位
moonfrog_labs_private_limited Moonfrog Labs Teen Patti Gold 単独で約1000万MAU、9000万ドルで買収
hola_networks Hola Networks Bright Data の系譜上の親会社であり、Hola の過去マーケティング基準でのピークユーザー数は数千万から約1億超の範囲
  • 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 など少なくとも3社の CTV 中心事業者がユーザー端末を住宅用プロキシの出口ノードとして収益化していたという点
  • PlayWorks は自社マーケティング資料に基づき、主要 TV プラットフォームと ISP 全般での CTV 配信、および数億世帯規模への到達を示している

Bright Data SDKがユーザーのデバイスを住宅用プロキシの出口ノードに変える仕組み

  • Bright Data SDKは、パブリッシャー向けのSDK統合ドキュメントと、Web向けのJavaScript variantを備えた公開文書化済みの商用製品

  • 分析は、配布中のiOSフレームワークのリバースエンジニアリングと30日間のランタイムトラフィック計測に基づいて構成

  • SDKはパートナーアプリ内のiOSフレームワークbrdsdk.frameworkの形で配布される

  • 認証のない設定

    • SDKは起動のたびに次のリクエストを呼び出す
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • このエンドポイントは意味のある認証なしで動作し、サーバーはアプリのバンドルIDであるappidとSDKバージョン文字列であるverの2つのクエリパラメータだけを確認する
    • パートナーアプリのApp Store掲載情報で見つかるバンドルIDとSDKバージョン文字列、任意生成UUIDを与えると、実機が受け取る応答と同一の設定が返る
    • 応答には、機能フラグ、バッテリー比率・CPU/メモリ上限・Wi‑Fi/セルラー規則のようなアイドル検知しきい値、国別帯域幅階層、パートナーmanifestを含む構造が入っている
    • 設定内には、デバイスがトラフィック中継資格を得るアイドル規則、VPN周辺でピアトラフィックをルーティングするフラグ、クロスプラットフォームのインストールを1つのIDに結び付ける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を送信元とするサードパーティーサイトへの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のしきい値内にあることを意味する
    • ユーザーが通話中であったり、画面を積極的に読んでいる状態でも、中継目的のアイドル状態と見なされる

  • クロスプラットフォームのID連携

    • 設定には次のdual_pairing mapが存在する
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • このmapは、同一ブランドのiOS、Windows、macOSインストールを1つのエンティティとして束ねるサーバー側の連結構造
    • 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は2つの独立したインスペクション回避を使用
    • Control plane: 設定取得とテレメトリpingは、URLSession・NSURLConnection ではなくCFNetworkの CFHTTPMessage プリミティブを基盤としており、モバイルアプリのセキュリティツールで一般的な URLSession レベルの計測、swizzling、network extension、URLProtocol subclassを無効化しつつ、システムプロキシは尊重するため、TLSインターセプト研究者には可視性が維持される
    • Data plane: ピアトンネルは、物理インターフェースを必須インターフェースとして設定した NWConnection ベースで、VPNを無効化し、スクレイピングが住宅向けIP上で実行されることを保証
    • MDM、企業VPNベースのトラフィック検査、家庭用ルーターのペアレンタルコントロールを使うセキュリティチームにとって最も敏感なチャネルは、可視性レイヤーを回避するよう設計された状態

国別の階層

  • 設定には国別の帯域幅しきい値が存在する
国 リレーの最小バッテリー 1日あたりの上限 月間上限
Uzbekistan 1% 1GB 30GB
Oman 1% 1GB 30GB
Qatar 20% 40MB 250MB
UAE 20% 40MB 250MB
default, worldwide 20% 50MB 500MB
  • Uzbekistan と Oman の端末では、バッテリー 1% までリレーが許可され、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 関連の制約により、3つの階層はいずれもトラフィックがネットワーク境界を通過するときにのみ機能する
  • iOS 端末がセルラー通信を使う場合、SDK の use_netifs バインディングによって、ピアトラフィックが企業 Wi-Fi を完全に迂回する条件が生まれる
  • 管理対象端末フリートの補完的統制としては MDM ベースのアプリバイナリスキャンがあり、インストール済みアプリから Swift シンボル BrdWebSocketFacade と BrdNetwork.DNSResolver を検索し、これらのシンボルを持つアプリを会社支給端末で禁止する方式
  • 特定のスマートTVやモバイルアプリが懸念される家庭のユーザーは、ルーターの DNS 設定で上記ホスト名をブロックする方法を利用できる
  • ブロックツールの例としては、Pi-hole、NextDNS、Cloudflare Gateway、ISP の同等機能がある

関連記事

2件のコメント

 
GN⁺ 2026-06-08
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 ブロックリストに追加した
    • 米国政府が、適切に規制していない商業企業を必要とし、その企業がプライバシー侵害を合法的な手段のように提供することで、政府が手を汚さずに済む構図に似ている

  • どんなスマートデバイスも Wi‑Fi には接続しない。接続なしで動かないなら要らない
    TV はただの表示装置として使い、HDMI 入力さえあれば十分だ

    • 出荷後に一度もインターネットと通信していないスマート TV があるが、かなり不安定な均衡だと感じている
      HDMI 画面の上に数秒出る「Services unavailable, press [menu] to troubleshoot」というトーストを客が見て、親切心から接続してしまわないか心配だ。そうなると 4〜5 年分のファームウェア更新が一気に入り、HDMI フィードからどうにか抽出して保存していた半 decade 分の視聴データがこの瞬間のために送信され、広告がそこら中に出る気がする
      たとえ今すぐ起きなくても、OS の奥深くに makeEverythingWorse みたいなフラグがあって、The Beast がほんの少し高いパッチ番号の匂いを嗅ぎつけたフェムト秒で有効になる気がする。結局、Samsung の誰かに私の好きな番組が HDMI2 だと知らせるという唯一の目的だけを果たして、壊れた状態になるだけだ
      母の TV でもその崖っぷちから引き戻したことがあるので、心配する価値はあると思う。空っぽの TV ホーム画面と線の入った電波塔アイコンが「うちにも Disney+ と CraveTV がありますよ……[menu] を押してください……息子がコーヒーテーブルに貼ったメモは気にしないでください」と誘惑しているようなものだ
    • 大丈夫。Amazon Sidewalk のような技術と安価で軽量な 4G/5G モジュールがあれば、もはや誰も接続の許可を求める必要はない
      古い機器を使うこともできるだろうが、時代遅れにはなりたくないだろう。デジタルの軛をそのまま受け入れないと、周囲の人に貧乏人か C.H.U.D. だと思われるかもしれない
    • この原則は理論上は理解できるが、TV で Netflix や YouTube のようなものを見たい現代の生活で、実際にどう回るのかはよくわからない
      TV かもしれないし Android ボックスかもしれないが、結局どこかでは第三者と、その上で別の第三者アプリを実行できるソフトウェアを信頼することになる。代替はローカルの Jellyfin サーバーだが、家族が見たがるコンテンツを入れようとすると、かなり高い確率で法を破ることになる
      個人的には家に TV がまったくないのが理想だが、家族を説得するのは簡単ではない ;-)
    • うちの TCL TV は、同意するGoogle のポリシーを読むためにまず接続しなければならない。接続しないなら、読んでいないポリシーに同意する格好になる
      幸い、接続性がなければこれによる被害範囲は事実上ない
    • 腹立たしいことに、TV をネットワークに接続して初めて得られる機能の一部は欲しい。特に、TV の電源オンや入力切り替えのようなものを、TV が公開する API で制御する機能だ
      外部インターネットアクセスを遮断した VLAN に入れれば管理できるが、そこまでしなければならないという事実自体が本当に面倒だ

  • 原則としてローカルネットワークで TV を遮断するのはよい。だが Amazon Fire デバイスはしばらくの間、Sidewalk を使って本隊へ戻る経路を作っていなかったか？
    近所の Ring ドアベルがデフォルト設定のままでも十分だったはずだ

  • SDK 設定に use_netifs: true フラグが入っており、このフラグにより SDK バイナリは NWConnection を作るとき、システムのデフォルト経路ではなく、特定の必須インターフェースである en0（Wi‑Fi）または 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を買ったが、いら立たしい3日間の後で道端に出した
      ブートループに陥り、UI入力の遅延が3秒ほどあったからだ。ネットワークに接続したことすらなかったのに、親切にもTVの製造時期である約10年前に公開されたSony Picturesの映画広告を表示してきた

  • 今確認してみたら、ネットワーク全体でAdGuardを使っている。TVではリクエストの80%がブロックされ、ネットワーク全体では約50%がブロックされている。狂っているレベルだ

  • この種のプロキシが違法でないのなら、少なくとも違法であるべきだと思う。インターネットルーティングやIPアドレスのリースと所有権に関する基本的な前提を回避する境界線上にあると言うだけでも、Bright Dataがそれを決済可能な製品としてパッケージ化していることを考えれば生ぬるい表現だ
    「あなたは、Bright Dataがときどきあなたのデバイスの余剰リソースと_IPアドレスを使ってインターネット上の公開Webデータをダウンロード_することを許可します」という文言がある
    エンドユーザーにとって誤解を招くのは、「公開Webデータをダウンロード」という表現だ。データが公開なら、なぜBright Data自身でダウンロードできないのか。おそらく相手がそれを望んでいないからだ。この製品は、金はあるがインターネット上で正当な理由により不利な立場にある誰かの代わりに、Bright Dataが「公開」データ提供者の望まない性質を回避するのを、ユーザーに手助けさせるものだ
    まったく嘆かわしいが、こういう方向に流れていくのは分かっていたので、正直なところ驚きもしないし、それほど心配でもない。人々はずっと前から財布で投票してきた。ここでプロキシとして使われるのは、プライバシー意識の高いJoe the Hackerではなく、一日の終わりに娯楽を求める私たちの両親や何百万人もの人々、そして幼い子どもを持つ親たちだ
    日を追うごとにダークインターネット理論はもっともらしく見えてきて、正直そちらに進んでも構わないと感じる。インターネットは、どんなルーティングでもホップごとに鍵が必要な封建的インターネットワークへと崩壊していくだろうし、そうなってこそ実際の人間——そして正直に言えばエージェントたちも——が、今まさに積極的に回避されている信頼をある程度維持できる

    • 完全に合法で、あなたの言うIPルーティングとアドレス所有権に関する法律は存在しない

  • ここで見えている問題の一つは、Tor出口ノードを運用するときと同じ問題だ。悪意ある利用者が自分の所在地を隠すために使える
    実際の犯人が、あなたのTVをプロキシとして使って児童性的虐待コンテンツをやり取りしているのに、警察があなたがそれを流通させていると判断して家に来る状況を想像すればいい

    • あらゆるものがユーザーに敵対的になっていくのが本当に嫌だ。ほとんどすべての専門家にならなければならず、既存の前提を覆す重大な変化が起きていないかとニュースを追い続けなければならない
      しかも、何かを見落として不満を言うと、擁護する人たちがどっと現れて、正当化したり、論点をそらしたり、会話をかき乱したりする
      せめてもの良い知らせは、こうした疲弊が一般の人々にも及んでいることだ。職場の同僚は、子ども向けの制限や上限をきちんと適用するには、自分が完全なWi-Fi/インターネット管理者にならなければならないと不満を漏らしていた
      ただただうんざりして言っている。ここで適切な解決策が何なのか、まだよく分からない
    • Bright Dataのようなグループは、顧客確認手続きをかなりしっかり整えている。警察の訪問でひと騒ぎして肝を冷やした後には、実際の加害者が刑務所に行くことになるだろう
 
GN⁺ 2026-06-07
Lobste.rsの意見

  • このプロトコルについて語るついでに、すべてのリクエストに対してランダム生成したゴミデータを自発的に返す逆ハニーポットを作れば、余ったトークンを持っている誰かにとって面白いバイブコーディングのプロジェクトになるかもしれない

    • わざわざプロトコルを実装する必要はなさそう。ログを見ると、こうした住宅用プロキシのかなりの部分は自分を隠すことに完全に失敗していて、単に簡単にゴミデータを返せる
      バイブコーディングすら不要で、すでにこういうことができるツールは数十個ある。その多くは1年以上にわたって、こうしたプロキシに延々とゴミデータをうまく提供してきた

  • なぜTVであれ他の家電であれ、インターネットに接続するのかまったく理解できない。そうしなければならない良い理由がない

    • 人々はTVでストリーミングサービスを見る。TVをインターネットに接続するのが、それを行う最も簡単な方法だ