สมาร์ตทีวีในห้องนั่งเล่นคือโหนดหนึ่งของเศรษฐกิจการสแครปข้อมูลด้วย AI

 (blog.includesecurity.com)
3 คะแนน โดย GN⁺ 2026-06-07 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bright Data SDK ที่ฝังอยู่ในแอปผู้บริโภค จะเปลี่ยนมือถือหรือสมาร์ตทีวีให้เป็นโหนดทางออกของพร็อกซีที่อยู่อาศัยภายใต้ความยินยอมของผู้ใช้ และส่งทราฟฟิกเว็บสแครปของลูกค้าผ่าน IP ภายในบ้าน
  • พร็อกซีที่อยู่อาศัย คือวิธีอ้อมเพื่อเข้าถึงเว็บไซต์เป้าหมายด้วย IP ของลูกค้าที่อยู่อาศัยแบบชำระเงิน ในสภาพแวดล้อมที่ Cloudflare, DataDome, HUMAN และรายอื่น ๆ จำกัดหรือบล็อกคำขอจาก IP คลาวด์ที่รู้จัก
  • Connected TV ไม่มีข้อจำกัดเรื่องแบตเตอรี่ เชื่อมต่อ Wi-Fi ตลอดเวลา และทำงานในสถานะสแตนด์บายได้ 24/7 จึงเป็นเงื่อนไขของพร็อกซีที่มี ความพร้อมใช้งานตลอดเวลา และ ถูกปล่อยทิ้งไว้ได้ มากกว่ามือถือ
  • iOS SDK รับเกณฑ์สถานะว่าง ขีดจำกัดแบนด์วิดท์ และรายชื่อพาร์ตเนอร์จาก endpoint การตั้งค่าที่ไม่มีการยืนยันตัวตน แล้วเปิด WebSocket peer tunnel เพื่อจัดการเทเลเมทรีสถานะอุปกรณ์และงานสแครป cmd_tun
  • แนวทางป้องกันเน้นที่การบล็อก DNS ของ proxyjs.* และ clientsdk.*, การกรอง SNI, การตรวจจับลายนิ้วมือใบรับรอง TLS และการสแกนไบนารีแอปผ่าน MDM โดย use_netifs บน iOS เป็นข้อจำกัดที่หลบเลี่ยงการมองเห็นแบบอิง VPN

ภาพรวม

  • นอกเหนือจากการคัดค้านระดับชุมชนต่อการสร้างดาต้าเซ็นเตอร์เพื่อเพิ่มขีดความสามารถด้าน AI ยังมีโครงสร้างที่ทำให้อุปกรณ์ภายในบ้านสามารถถูกใช้เพื่อเก็บรวบรวมข้อมูลแบบกระจายสำหรับการฝึก AI ได้
  • Bright Data ขายสิทธิ์เข้าถึงเครือข่ายพร็อกซีที่อยู่อาศัยซึ่งมี IP ภายในบ้านมากกว่า 400M+ รายการ สำหรับให้ลูกค้าใช้ส่งทราฟฟิกเว็บสแครป โดยแหล่งที่มาคือ SDK ที่ฝังอยู่ในแอปผู้บริโภค
  • SDK ดังกล่าวจะเปลี่ยนมือถือหรือสมาร์ตทีวีให้เป็นโหนดทางออกภายใต้ความยินยอมของผู้ใช้ โดยการวิเคราะห์นี้มุ่งดูวิธีการทำงานของ SDK, แพลตฟอร์มที่ใช้กระจาย และเหตุผลที่ทีวีเชื่อมต่ออินเทอร์เน็ตเหมาะกับการเป็นพร็อกซีเว็บสแครปสำหรับโมเดล AI

ทำไมเรื่องนี้สำคัญตอนนี้

  • บริษัท AI พึ่งพาคอนเทนต์จากการทำเว็บสแครปสำหรับการพรีเทรน การค้นหา/การดึงข้อมูลเสริมการค้นหา agent grounding และฟีเจอร์ค้นหา
  • เว็บสมัยใหม่เป็นสภาพแวดล้อมที่สแครปจากดาต้าเซ็นเตอร์ได้ไม่ง่าย โดย Cloudflare, DataDome, HUMAN และรายอื่น ๆ จำกัดหรือบล็อกคำขอจาก IP คลาวด์ที่รู้จัก
  • ทางเลือกคือ พร็อกซีที่อยู่อาศัย ที่เข้าถึงเว็บไซต์เป้าหมายจาก IP ของลูกค้าที่อยู่อาศัยแบบชำระเงิน เช่น การเชื่อมต่อของสมาชิก Comcast หรือ T-Mobile
  • คำพูดที่อ้างจากรายงานของ Krebs ในเดือนตุลาคม 2025 ระบุว่า “พร็อกซีล้นเกินจาก Aisuru และแหล่งอื่น ๆ กำลังกระตุ้นความพยายามเก็บเกี่ยวข้อมูลขนาดใหญ่ที่เชื่อมโยงกับโครงการ AI หลายโครงการ”
  • งานวัดผลเชิงวิชาการ ย้อนหลังไปถึงปี 2019 พบว่าเครือข่ายลักษณะนี้ถูกใช้ในทางที่ผิดอย่างท่วมท้น และ FBI ก็ออกคำเตือนอย่างเป็นทางการเมื่อต้นปีนี้
  • รายงานส่วนใหญ่ก่อนหน้านี้มุ่งไปที่แหล่งจัดหาพร็อกซีที่อยู่อาศัยผิดกฎหมาย เช่น บอตเน็ตอย่าง Aisuru และ Kimwolf, แอปที่ถูกทำให้เป็นโทรจันอย่าง PROXYLIB, หรือฮาร์ดแวร์ IoT ที่ติดเชื้อมาก่อนอย่าง IPIDEA
  • ฝั่งอุปทานที่ถูกกฎหมายได้รับการตรวจสอบค่อนข้างน้อยกว่า โดย Bright Data โฆษณาว่าเป็นเครือข่ายพร็อกซีที่อยู่อาศัยใหญ่ที่สุดในโลกตามเกณฑ์การตลาดของตนเอง และโปรโมต “150M+ IPs” ที่อิงจาก SDK แบบยินยอมซึ่งฝังในแอปพาร์ตเนอร์

ทำไม Connected TV จึงเป็นพร็อกซีในอุดมคติ

ปัจจัย มือถือ สมาร์ตทีวี / CTV
พลังงาน ใช้แบตเตอรี่เกือบทั้งวัน เสียบไฟตลอดเวลา
เครือข่าย Wi-Fi + เซลลูลาร์ Wi-Fi ตลอดเวลา, ความเร็วสูง
เวลาทำงาน เป็นช่วง ๆ 24/7 ในสถานะสแตนด์บาย
ขีดจำกัดแบนด์วิดท์ ต่ำ, ถูกจำกัดโดยเซลลูลาร์ แทบไม่จำกัด
ความใส่ใจของผู้ใช้ ใช้งานอย่างใกล้ชิด มักถูกปล่อยทิ้งไว้
UI การยินยอม ข้อความบนหน้าจอมือถือ ข้อความที่ต้องเลื่อนดูด้วยปุ่มทิศทางบนรีโมตทีวี
การกำกับดูแลจากองค์กร·ครอบครัว สูงกว่า เช่น MDM, mobile EDR แทบไม่มี
  • ทีวีเป็นอุปกรณ์ที่แบตเตอรี่ไม่มีวันเหลือ 1%, ไม่ย้ายไปมาระหว่างเครือข่าย Wi-Fi บ่อย ๆ และไม่ถูกล็อกขณะผู้ใช้หลับ
  • ผู้เผยแพร่พาร์ตเนอร์บางรายเปิดเผยความสัมพันธ์กับ Bright Data ในเอกสารนโยบายความเป็นส่วนตัว โดย นโยบายความเป็นส่วนตัวของ PlayWorks เป็นหนึ่งในตัวอย่าง
  • การเปิดเผยในนโยบายความเป็นส่วนตัวไม่ใช่จุดควบคุมที่เหมาะกับทีวี เพราะการเลื่อนเอกสารกฎหมายด้วยปุ่มทิศทางบนรีโมตทำได้ยาก และหน้าต่างยินยอมในแอปก็มีโครงสร้างที่ไม่สามารถสื่อได้ว่าลูกค้า Bright Data แบบชำระเงินกำลังส่งทราฟฟิกสแครปผ่านอินเทอร์เน็ตภายในบ้านของผู้ใช้
  • หน้าจอ opt-in ของแอป Roku ชื่อ Petflix ที่ The Verge บันทึกไว้ ใช้ข้อความว่า “เพื่อให้เห็นโฆษณาน้อยลงและใช้งานฟรี โปรดอนุญาตให้ Bright Data ใช้ทรัพยากรส่วนเกินของอุปกรณ์และที่อยู่ IP ของคุณเป็นครั้งคราว เพื่อดาวน์โหลดข้อมูลเว็บสาธารณะจากอินเทอร์เน็ต”
  • แม้หน้าต่างของ Petflix จะใช้คำว่า “เป็นครั้งคราว” แต่ max_bw_monthly_wifi: 200,000,000,000 ในการตั้งค่า SDK ที่เปิดให้ดูสาธารณะระบุว่างบ Wi-Fi เริ่มต้นต่อเดือนอยู่ที่ 200GB

เป้าหมายที่ Bright Data ระบุว่าเป็นพาร์ตเนอร์

  • Bright Data เปิดเผย endpoint manifest ของพาร์ตเนอร์ที่ใครก็เข้าถึงได้โดยไม่ต้องยืนยันตัวตน
  • รายการระบุตัวตนที่เชื่อถือได้สูงตามแหล่งข้อมูลสาธารณะ
Partner ID Entity ขนาด
playworks_digital PlayWorks Digital Ltd มีเกม CTV มากกว่า 400 รายการ เข้าถึงครัวเรือนที่มีทีวีราว 250M ผ่าน Comcast·Sky·Cox·LG·Samsung·Vizio·Roku
cloudtv CloudTV ถูกรวมเข้ากับแบรนด์ทีวี 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 Messenger 250M–820M
supercent_inc Supercent ผู้เผยแพร่มือถือเกาหลีอันดับ 1 ตามจำนวนดาวน์โหลดในปี 2023
moonfrog_labs_private_limited Moonfrog Labs Teen Patti Gold เพียงแอปเดียวมี MAU ราว 10M และถูกซื้อกิจการด้วยมูลค่า 90 ล้านดอลลาร์
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 เผยแพร่รายชื่อนี้ผ่าน public endpoint ที่ไม่มีการยืนยันตัวตน และมีผู้ประกอบการฝั่ง CTV อย่างน้อยสามราย ได้แก่ PlayWorks, CloudTV และ Longvision ที่นำอุปกรณ์ของผู้ใช้ไปสร้างรายได้ในฐานะ residential proxy exit node
  • PlayWorks อ้างในเอกสารการตลาดของตนเองว่ามีการกระจาย CTV ครอบคลุมทั้งแพลตฟอร์มทีวีหลักและ ISP พร้อมตัวเลขการเข้าถึงในระดับหลายร้อยล้านครัวเรือน

Bright Data SDK เปลี่ยนอุปกรณ์ของผู้ใช้ให้เป็นโหนดทางออกของพร็อกซีที่อยู่อาศัยอย่างไร

  • Bright Data SDK เป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีเอกสารสาธารณะ พร้อม เอกสารการผสานรวม SDK สำหรับผู้เผยแพร่ และ JavaScript variant สำหรับเว็บ

  • การวิเคราะห์นี้อ้างอิงจากการรีเวิร์สเอนจิเนียร์ริง iOS framework ที่กำลังแจกจ่ายอยู่ และการวัดทราฟฟิกขณะรันไทม์เป็นเวลา 30 วัน

  • SDK ถูกแจกจ่ายในรูปของ iOS framework ชื่อ brdsdk.framework ภายในแอปพาร์ตเนอร์

  • การตั้งค่าที่ไม่มีการยืนยันตัวตน

    • ทุกครั้งที่เริ่มทำงาน SDK จะเรียกคำขอต่อไปนี้
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • เอนด์พอยต์นี้ทำงานโดยแทบไม่มีการยืนยันตัวตนที่มีความหมาย และเซิร์ฟเวอร์ตรวจสอบเพียงพารามิเตอร์คิวรีสองตัวคือ appid ซึ่งเป็น App bundle ID และ ver ซึ่งเป็นสตริงเวอร์ชันของ SDK
    • หากระบุ bundle ID ที่หาได้จากหน้า App Store ของแอปพาร์ตเนอร์ พร้อมสตริงเวอร์ชัน SDK และ UUID ที่สุ่มขึ้นมา ก็จะได้การตั้งค่าชุดเดียวกับที่อุปกรณ์จริงได้รับ
    • คำตอบประกอบด้วยฟีเจอร์แฟล็ก, ค่า threshold สำหรับตรวจจับการว่างงาน เช่น สัดส่วนแบตเตอรี่, เพดาน CPU/หน่วยความจำ, กฎ Wi‑Fi/เซลลูลาร์, ระดับแบนด์วิดท์แยกตามประเทศ และโครงสร้างที่มี manifest ของพาร์ตเนอร์
    • ภายในการตั้งค่ามีกฎ idle ที่กำหนดว่าอุปกรณ์จะมีสิทธิ์รีเลย์ทราฟฟิกเมื่อใด, แฟล็กสำหรับ route ทราฟฟิกของเพียร์ผ่านบริเวณรอบ VPN, map ที่เชื่อมการติดตั้งข้ามแพลตฟอร์มให้เป็นตัวตนเดียวกัน และขีดจำกัดแบนด์วิดท์รายประเทศ

  • Peer tunnel

    • หลังดึงการตั้งค่าแล้ว SDK จะเปิด WebSocket แบบคงอยู่ไปยังที่อยู่นี้
    • wss://proxyjs.brdtnet.com:443
    • ชื่อโฮสต์นี้ ณ เวลาที่เขียนบทความ resolve ไปยัง 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 ฝั่งไคลเอนต์ แต่เป็นเบาะแสในการระบุ peer tunnel plane
    • ปัจจุบันบริการพร็อกซีที่ให้ลูกค้าใช้งานทำงานบนโดเมนแบรนด์ brightdata.com ดังนั้นทราฟฟิก luminatinet.com และ brdtnet.com ในเครือข่ายจึงเป็น peer tunnel plane
    • เซิร์ฟเวอร์ระบุตัวเองว่า uWebSockets: 20
    • เอนด์พอยต์ฝั่งเพียร์ไม่ต้องการการยืนยันตัวตนสำหรับการอัปเกรด และหลังรับ WebSocket upgrade ที่มี TLS ถูกต้องแล้ว จะส่งแอปพลิเคชันเลเยอร์เฟรมที่คืนค่า public IP ของไคลเอนต์กลับมาทันที
    • ลำดับขั้นของแฮนด์เชก
      1. เซิร์ฟเวอร์ → ไคลเอนต์ tunnel_init: สร้างเซสชันและคืนค่า public IP ของไคลเอนต์
      1. เซิร์ฟเวอร์ → ไคลเอนต์ cid_set: กำหนดตัวระบุสำหรับติดตามเซสชันในรูปแบบ <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> และยืนยันว่าตรงกับฟิลด์ cid ใน telemetry ของอุปกรณ์จริง
      1. เซิร์ฟเวอร์ → ไคลเอนต์ status_get: polling สถานะการว่างของอุปกรณ์, แบตเตอรี่, ประเภทเครือข่าย, แบนด์วิดท์ที่ใช้ได้ และอุปกรณ์จะตอบกลับด้วย telemetry ต่อเนื่อง เช่น 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. หลังแฮนด์เชกเสร็จ หากอุปกรณ์รายงานสถานะที่เอื้ออำนวย เลเยอร์จับคู่งานของเซิร์ฟเวอร์สามารถ push เฟรม cmd_tun มาได้ และ SDK จะนำไปใช้รันคำขอ HTTP ไปยังเว็บไซต์ของบุคคลที่สามโดยใช้งาน residential IP ของผู้ใช้เป็นต้นทาง
    • ทุกเฟรมใน WebSocket เป็น plain JSON ที่มี envelope คงที่
    • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
    • คำสั่งที่ดึงออกมาจากไบนารีและยืนยันได้จากการสื่อสารจริง
    • | ทิศทาง | cmd | วัตถุประสงค์ |
    • |---|---|---|
    • | Server → Client | tunnel_init | เปิดเซสชัน, echo public IP |
    • | Server → Client | cid_set | กำหนดตัวระบุเซสชัน |
    • | Server → Client | status_get | polling สถานะ idle, แบตเตอรี่ และแบนด์วิดท์ของอุปกรณ์ |
    • | Server → Client | cmd_tun / tun | ส่งงาน scraping |
    • | Server → Client | dns | ขอให้ resolve 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 | ส่ง log สำหรับวินิจฉัยไปยังเซิร์ฟเวอร์ |
    • ไม่มี message signature, HMAC, client certificate หรือ device attestation และสิ่งที่แยกเพียร์ที่ได้รับงานจริงออกจากกันมีเพียงชั้น TLS กับตัวกรองชื่อเสียง IP ของเซิร์ฟเวอร์เท่านั้น
    • สำหรับผู้อ่านที่คุ้นเคยกับการออกแบบโปรโตคอลของมัลแวร์เชิงพาณิชย์ ระดับความปลอดภัยนี้ในทางปฏิบัติต่ำกว่า C2 ทั่วไปเสียอีก

  • เงื่อนไขที่ SDK มองว่า “idle”

    • การตั้งค่าระบุกฎสถานะของอุปกรณ์ที่สามารถรีเลย์ทราฟฟิกของผู้อื่นได้
    "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 คำว่า “idle” จึงไม่ได้หมายความว่าผู้ใช้อยู่ห่างจากอุปกรณ์ แต่หมายถึง CPU, หน่วยความจำ และแบตเตอรี่อยู่ภายใน threshold ของ SDK
    • แม้ผู้ใช้จะกำลังคุยโทรศัพท์หรือกำลังอ่านหน้าจออย่างจริงจัง ก็ยังถูกนับเป็นสถานะ idle เพื่อวัตถุประสงค์ในการรีเลย์

  • การเชื่อมตัวตนข้ามแพลตฟอร์ม

    • ภายในการตั้งค่ามี dual_pairing map ดังต่อไปนี้
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • map นี้เป็นโครงสร้างการเชื่อมโยงฝั่งเซิร์ฟเวอร์ที่ผูกการติดตั้ง iOS, Windows และ macOS ของแบรนด์เดียวกันเข้าด้วยกันเป็นเอนทิตีเดียว
    • ฟิลด์ http3_enabled: true เป็นแฟล็กสำหรับการส่งผ่านเพียร์บน QUIC และเวอร์ชันในอนาคตอาจย้าย peer tunnel จาก TCP/443 ไปเป็น UDP/443
    • ผู้ป้องกันที่ตรวจจับ WebSocket ด้วยการติดตามการเชื่อมต่อ TCP อาจพบว่าวิธีตรวจจับนี้ใช้ไม่ได้อีกเมื่อมีการย้ายไปยัง UDP/443

  • การหลบเลี่ยงการตรวจสอบ

    • แฟล็ก use_netifs: true ในการตั้งค่า SDK เป็นเงื่อนไขที่ทำให้โค้ดไบนารีของ SDK สร้าง NWConnection บนอินเทอร์เฟซบังคับเฉพาะ แทนที่จะใช้เส้นทางปริยายของระบบ
    • อินเทอร์เฟซบังคับดังกล่าวคือ en0 สำหรับ Wi‑Fi หรือ pdp_ip0 สำหรับเซลลูลาร์
    • บน iOS วิธีนี้จะ bypass อินเทอร์เฟซ tun0 ของ VPN ที่ผู้ใช้ตั้งค่าไว้โดยสมบูรณ์ และแม้ทราฟฟิก HTTPS อื่นของแอปจะผ่าน VPN แต่ peer tunnel จะไม่ผ่าน VPN ที่ผู้ใช้ตั้งค่าไว้

  • สภาพแวดล้อมการวิจัยการดักจับ TLS แบบโปร่งใสสามารถจับทุกการเรียก HTTPS ของ SDK ได้ แต่กลับไม่สามารถจับ peer tunnel ของ proxyjs.brdtnet.com:443 ได้ ทั้งที่พอร์ต 443 ถูกรีไดเร็กต์ไปยังตัวตรวจสอบอย่างชัดเจนแล้ว

    • การหลบเลี่ยงใช้ API NWParameters.requiredInterface ที่ Apple มีเอกสารอธิบายไว้
    • SDK ใช้การหลบเลี่ยงการตรวจสอบ 2 แบบที่แยกจากกัน
    • Control plane: การดึงค่าคอนฟิกและ telemetry ping ทำงานบนพื้นฐานของ primitive CFHTTPMessage ของ CFNetwork แทน URLSession·NSURLConnection ทำให้เครื่องมือความปลอดภัยของแอปมือถือที่มักใช้การทำ instrumentation ระดับ URLSession, swizzling, network extension, และ URLProtocol subclass ใช้การไม่ได้ แต่ยังคงเคารพระบบพร็อกซี จึงยังคงมีการมองเห็นสำหรับนักวิจัยการดักจับ TLS
    • Data plane: peer tunnel ทำงานบนพื้นฐาน NWConnection ที่ตั้งค่า physical interface เป็น required interface ทำให้ 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 วัน ได้ทำการดักจับผ่านพร็อกซีสำหรับสกัดกั้น TLS บนอุปกรณ์ iOS ที่รันแอปพาร์ตเนอร์ซึ่งติดตั้งแบบยินยอมแล้ว โดยแอปตัวอย่างรวมถึง XYO COIN ที่ฝัง Bright SDK
  • ทำ static analysis กับ brdsdk.framework version 1.532.120 และไบนารี iOS arm64
  • โฮสต์เนมเฉพาะ, ลายนิ้วมือใบรับรอง และโครงสร้างพื้นฐาน TLS ของ Bright Data เป็นสิ่งที่ใครก็ตามที่ส่งคำขอแบบเดียวกันสามารถสังเกตเห็นได้แบบสาธารณะ
  • ในเอกสารไม่มีข้อมูลระบุตัวตนรายเซสชันของ research fleet หรือ research client

ไทม์ไลน์

  • 11 พฤษภาคม 2026 ส่งอีเมลแจ้งเตือนก่อนเผยแพร่ไปที่ privacy@brightdata.com
  • จนถึงเวลาที่เผยแพร่ ยังไม่มีการตอบกลับต่อการแจ้งเตือนดังกล่าว

แนวทางป้องกัน

  • ทราฟฟิกทิ้ง fingerprint ที่ชัดเจนไว้ที่ขอบเครือข่าย และ SDK ถูกออกแบบให้ทิ้งสัญลักษณ์ที่ระบุตัวได้ไว้ในไบนารีของแอป
  • แนวทางที่ 1 การบล็อก DNS เป็นวิธีที่ง่ายและมีประสิทธิภาพสำหรับอุปกรณ์ที่ถูก route ผ่านเครือข่าย
    • proxyjs.brdtnet.com
    • proxyjs.luminatinet.com
    • proxyjs.bright-sdk.com
    • clientsdk.bright-sdk.com
    • clientsdk.brdtnet.com
  • การบล็อก proxyjs.* จะตัด peer tunnel และไม่กระทบลูกค้าที่ใช้งานบริการพร็อกซีของ Bright Data อย่างถูกต้องตามกฎหมายสำหรับลูกค้าในโดเมนอื่น
  • แนวทางที่ 2 การกรอง TLS SNI คือการบล็อกหรือแจ้งเตือน TLS handshake ที่ server_name ตรงกับ *.brdtnet.com, *.luminatinet.com, *.luminati.io
  • การกรอง SNI ทำงานที่ขอบเครือข่ายได้โดยไม่ต้องตรวจสอบ TLS
  • แนวทางที่ 3 การตรวจจับลายนิ้วมือใบรับรอง TLS คือการบล็อกหรือแจ้งเตือนตามลายนิ้วมือต่อไปนี้
    • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
    • .luminatinet.com → SHA256 5028612e625befea…
  • ลายนิ้วมือใบรับรองมีเสถียรภาพจนกว่าจะมีการเปลี่ยนใบรับรอง Sectigo โดยใบรับรองปัจจุบันมีผลใช้ได้ถึงกลางปี 2026
  • เนื่องจากข้อจำกัดที่เกี่ยวข้องกับ use_netifs ทั้งสามระดับจึงทำงานได้ก็ต่อเมื่อทราฟฟิกผ่านขอบเครือข่ายเท่านั้น
  • เมื่ออุปกรณ์ iOS ใช้เครือข่ายเซลลูลาร์ การ bind use_netifs ของ SDK ทำให้ทราฟฟิกแบบเพียร์ข้ามเครือข่าย Wi‑Fi ขององค์กรไปได้โดยสมบูรณ์
  • มาตรการควบคุมเสริมสำหรับ fleet ของอุปกรณ์ที่มีการจัดการคือการสแกนไบนารีของแอปด้วย MDM โดยค้นหา Swift symbol BrdWebSocketFacade และ BrdNetwork.DNSResolver ในแอปที่ติดตั้ง และห้ามแอปที่มีสัญลักษณ์ดังกล่าวบนอุปกรณ์ของบริษัท
  • ผู้ใช้ตามบ้านที่กังวลเกี่ยวกับสมาร์ตทีวีหรือแอปมือถือบางตัวสามารถใช้วิธีบล็อกโฮสต์เนมข้างต้นในค่า DNS ของเราเตอร์ได้
  • ตัวอย่างเครื่องมือสำหรับการบล็อกได้แก่ Pi-hole, NextDNS, Cloudflare Gateway หรือความสามารถเทียบเท่าจาก ISP

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2026-06-08
ความเห็นจาก Hacker News

  • หลังจากดึงค่าตั้งค่าแล้ว SDK จะเปิด WebSocket แบบถาวรไปที่ wss://proxyjs.brdtnet.com:443 และชื่อโฮสต์นี้ก็ถูกแปลงเป็น IP ของ AWS Global Accelerator
    ทั้งตัวสแครปเปอร์และเว็บไซต์ที่ถูกสแครปมีความเป็นไปได้สูงว่าจะโฮสต์อยู่บน AWS เหมือนกัน แต่กลับทำทีเหมือนไม่เกี่ยวกันแล้วเล่นเกม แมวจับหนู กันอย่างซับซ้อน ซึ่งก็ดูประชดดี

    • Cloudflare ยังขายบริการป้องกัน DDoS ให้กับ แดชบอร์ดควบคุม DDoS ด้วย
    • Bright Data ก็มีสินค้าอยู่บน AWS Marketplace เช่นกัน
      https://aws.amazon.com/marketplace/seller-profile?id=bf9b432...
    • ผมเพิ่มมันเข้าไปใน รายการบล็อก DNS ทันที
    • มันคล้ายกับโครงสร้างที่รัฐบาลสหรัฐต้องพึ่งพาบริษัทเอกชนเชิงพาณิชย์ที่ไม่ได้ถูกกำกับดูแลอย่างจริงจัง แล้วปล่อยให้บริษัทเหล่านั้นให้บริการ การละเมิดความเป็นส่วนตัว ราวกับเป็นเครื่องมือที่ถูกกฎหมาย เพื่อให้รัฐบาลล้างมือได้

  • ผมไม่เชื่อม อุปกรณ์อัจฉริยะ ใด ๆ เข้ากับ Wi‑Fi ถ้ามันทำงานไม่ได้โดยไม่มีการเชื่อมต่อ ผมก็ไม่ต้องการมัน
    ทีวีก็ใช้เป็นแค่อุปกรณ์แสดงผลธรรมดา แค่มีอินพุต HDMI ก็พอ

    • ผมมีสมาร์ตทีวีเครื่องหนึ่งที่ไม่เคยติดต่ออินเทอร์เน็ตเลยแม้แต่ครั้งเดียวตั้งแต่ออกจากโรงงาน แต่รู้สึกว่ามันเป็นสมดุลที่เปราะบางมาก
      ผมกลัวว่าแขกจะเห็นข้อความลอยขึ้นมาบนภาพ HDMI ไม่กี่วินาทีว่า “Services unavailable, press [menu] to troubleshoot” แล้วด้วยความหวังดีจะเผลอเชื่อมต่อมันเข้าไป จากนั้นเฟิร์มแวร์อัปเดตสะสม 4–5 ปีก็จะถาโถมเข้ามาทีเดียว แล้วข้อมูลการรับชมครึ่งทศวรรษที่มันพยายามแกะและเก็บจากสัญญาณ HDMI ไว้ก็จะถูกส่งออกไปพอดี พร้อมโฆษณาที่โผล่มาทั่วทุกแห่ง
      ต่อให้จะไม่เกิดขึ้นทันที ผมก็รู้สึกเหมือนมีแฟลกอะไรสักอย่างแบบ makeEverythingWorse ซ่อนอยู่ลึก ๆ ใน OS และจะถูกเปิดในระดับเฟมโตวินาทีที่ The Beast ได้กลิ่นหมายเลขแพตช์ที่สูงขึ้นอีกนิด สุดท้ายก็พังไปหลังจากบรรลุเป้าหมายเดียวคือบอกใครสักคนที่ Samsung ว่ารายการโปรดของผมคือ HDMI2
      ผมเคยต้องถอยแม่ออกมาจากขอบเหวนั้นกับทีวีของเธอเหมือนกัน เลยคิดว่ากังวลแบบนี้ก็สมเหตุสมผล หน้าจอโฮมทีวีที่ว่างเปล่ากับไอคอนเสาส่งสัญญาณมีขีดพาดอยู่เหมือนกำลังกระซิบว่า “เราก็มี Disney+ กับ CraveTV นะ... กด [menu] สิ... ไม่ต้องสนใจโน้ตที่ลูกชายคุณแปะไว้บนโต๊ะกาแฟหรอก”
    • ไม่เป็นไรหรอก ถ้ามีเทคโนโลยีอย่าง Amazon Sidewalk กับโมดูล 4G/5G ราคาถูกและเบา ตอนนี้ก็ไม่มีใครจำเป็นต้องขออนุญาตเชื่อมต่อจากคุณอีกแล้ว
      คุณอาจใช้เครื่องรุ่นเก่าก็ได้ แต่คุณก็ไม่อยากตกยุคใช่ไหมล่ะ ถ้าคุณไม่ยอมรับแอกดิจิทัลเฉย ๆ คนรอบตัวก็อาจคิดว่าคุณจนหรือเป็น C.H.U.D.
    • ผมเข้าใจหลักการนี้ในทางทฤษฎี แต่ไม่ค่อยแน่ใจว่ามันจะใช้ได้จริงอย่างไรในชีวิตสมัยใหม่ที่อยากดู Netflix หรือ YouTube บนทีวี
      มันอาจเป็นทีวีหรือ Android box ก็ได้ แต่สุดท้ายคุณก็ต้องไว้ใจซอฟต์แวร์ของบุคคลที่สามที่เปิดให้แอปของบุคคลที่สามอื่น ๆ รันอยู่บนนั้นได้อยู่ดี ทางเลือกคือมี เซิร์ฟเวอร์ Jellyfin ภายในบ้าน แต่ถ้าจะใส่คอนเทนต์ที่ครอบครัวอยากดูลงไป ก็มีโอกาสสูงมากที่จะผิดกฎหมาย
      สำหรับผมแล้ว ถ้าที่บ้านไม่มีทีวีเลยคงจะดีกว่า แต่เกลี้ยกล่อมคนในครอบครัวไม่ง่ายเลย ;-)
    • ทีวี TCL ของผมบังคับให้เชื่อมต่อก่อนถึงจะอ่าน นโยบายของ Google ที่ต้องกดยอมรับได้ ถ้าไม่เชื่อมต่อก็เท่ากับยอมรับนโยบายที่ยังไม่ได้อ่าน โชคดีที่ถ้าไม่มีการเชื่อมต่อจริง ๆ ขอบเขตความเสียหายจากเรื่องนี้ก็แทบไม่มี
    • ที่น่าหงุดหงิดคือผมก็อยากได้ฟีเจอร์บางอย่างที่ต้องเชื่อมทีวีเข้ากับเครือข่าย โดยเฉพาะการควบคุมอย่างการเปิดทีวีหรือเลือกอินพุตผ่าน API ที่ทีวีเปิดให้ใช้
      ถ้าเอามันไปไว้ใน VLAN ที่บล็อกการออกอินเทอร์เน็ตภายนอกก็ยังจัดการได้ แต่แค่ต้องทำถึงขั้นนั้นก็น่ารำคาญมากแล้ว

  • โดยหลักการแล้ว การบล็อกทีวีออกจากเครือข่ายภายในเป็นเรื่องดี แต่พวกอุปกรณ์ Amazon Fire ไม่ได้เคยใช้ Sidewalk สร้างเส้นทางกลับฐานอยู่ช่วงหนึ่งหรือ?
    แค่กริ่งประตู Ring ของเพื่อนบ้านยังคงตั้งค่าเริ่มต้นไว้ก็น่าจะพอแล้ว

  • ในค่าตั้งค่า SDK มีแฟลก use_netifs: true อยู่ และแฟลกนี้ทำให้ในไบนารีของ SDK ตอนสร้าง NWConnection มันจะระบุอินเทอร์เฟซบังคับเฉพาะอย่าง en0 (Wi‑Fi) หรือ pdp_ip0 (เซลลูลาร์) แทนที่จะใช้เส้นทางระบบตามค่าเริ่มต้น
    บน iOS ผลคือมันข้ามอินเทอร์เฟซ tun0 ของ VPN ที่ตั้งค่าไว้ไปอย่างสมบูรณ์ ถึงแม้ทราฟฟิก HTTPS ส่วนอื่นของแอปจะวิ่งผ่าน VPN แต่ peer tunnel นี้จะไม่ผ่าน VPN ที่ผู้ใช้ตั้งไว้
    กรณีใช้งานที่ชอบธรรมของ API แบบนี้คืออะไร? มีเมื่อไรและเพราะอะไรที่แอปควรได้รับอนุญาตให้ ข้าม VPN ที่ผู้ใช้ตั้งค่าไว้?

    • ถ้าจะมีกรณีใช้งานที่ชอบธรรม ก็น่าจะเป็นกรณีที่แอปนั้น เป็นแอปพลิเคชันที่ให้บริการ VPN เอง หรือเป็นแอปที่ถูกออกแบบมาให้สื่อสารกับอะไรบางอย่างบนเครือข่ายใกล้ตัวภายใน มากกว่าจะไปยังปลายทางที่เข้าถึงได้ทั่วโลก
    • ถ้าการทำ full tunneling มีปัญหาชั่วคราว บางครั้ง split tunneling ก็ช่วยเลี่ยงปัญหาที่เกิดจาก VPN ได้
      แต่ผมก็คิดว่าแอปไม่ควรข้ามสิ่งอย่างขอบเขตเครือข่ายอยู่ดี

  • ขอถามแบบใส ๆ หน่อย ถ้าผมอยากเรียนรู้วิธีตรวจจับอะไรแบบนี้บนอุปกรณ์ของผม—ส่วนใหญ่เป็น iOS—หรือบนเครือข่ายบ้าน ควรค้นหาคำว่าอะไร?
    ผมอยากหาแอปที่มี SDK นี้ทำงานอยู่บนอุปกรณ์ของผมแล้วลบทิ้ง

    • อาจมีแหล่งข้อมูลที่ดีกว่านี้ แต่ถ้าคุณมี Mac ด้วย บทความนี้ก็ดูโอเคสำหรับการเริ่มต้น
      https://www.thequantizer.com/tutorials/wireshark-iphone-traf...
      ผมเองก็ไม่ได้ไล่รอยแบบนี้มาสักพักแล้ว แต่ Wireshark ใช้งานง่ายมาก และถ้ามีข้อมูลเครือข่ายโผล่มาให้ดู ก็มีข้อมูลอ้างอิงออนไลน์เยอะมากเช่นกัน
      เรื่องที่มันข้าม VPN ได้นี่น่ากลัวเป็นพิเศษ และผมว่าทั้งหมดนี้ก็น่ากลัวไปหมด โดยส่วนตัวแล้วผมอยากให้มีการจำกัดปริมาณข้อความที่ใส่ไว้ในข้อกำหนดการให้บริการได้ ตอนนี้ไม่มีใครอยากอ่านอะไรยาวขนาดนั้นแล้ว

  • มาตรการบรรเทาที่เสนอมา ดูอ่อนเกินไป
    การบล็อก DNS และการกรอง SNI นั้น ถ้าประเด็นนี้ได้รับความสนใจมากพอ ก็คาดว่า Bright Data จะหมุนเปลี่ยน endpoint ไปเรื่อย ๆ แม้ทุกแอปที่รวม SDK นี้ไว้จะต้องใช้เวลาตามให้ทัน แต่ถ้าฉลาดพอ SDK ก็น่าจะมีการเชื่อมต่อ command-and-control สำรองสำหรับลองใช้ไว้แล้ว เมื่อเข้าถึง endpoint ปัจจุบันต่อเนื่องเป็นเวลานานไม่ได้
    ลายนิ้วมือ TLS เป็นสิ่งที่เปลี่ยนได้เรื่อย ๆ ด้วยต้นทุนที่ถูกที่สุด ตราบใดที่ SDK ไม่ตรึงค่าไว้
    โซลูชัน MDM แทบเข้าถึงไม่ได้เลยสำหรับผู้ใช้ทั่วไป และก็ยังไม่ชัดเจนว่าชื่อ SDK จะคงที่พอให้พึ่งพาได้แค่ไหน
    ไม่ได้แปลว่ามีแนวทางที่ดีกว่านะ พฤติกรรมแบบนี้น่าจะต้องถูก Apple และ Google ห้ามไว้อย่างชัดเจน และยกเลิกบัญชีผู้เผยแพร่ทันที

  • ไฟร์วอลล์ของฉันไม่ควรบล็อกการเข้าถึงโลกภายนอก แค่ยอมให้สิ่งที่ Home Assistant ควบคุมเท่านั้น

    • สมาร์ตทีวีหลายรุ่นมีโฆษณาฝังมาในตัว ฉันเคยซื้อ Sony Bravia มือสองมา แล้วก็เอาไปวางทิ้งข้างถนนหลังจากหงุดหงิดได้สามวัน
      เพราะมันบูตลูป และ UI ก็ดีเลย์ตอนรับอินพุตประมาณ 3 วินาที ฉันไม่เคยต่อมันเข้ากับเครือข่ายเลยด้วยซ้ำ แต่มันก็ยังใจดีพอจะโชว์โฆษณาหนังจาก Sony Pictures ที่เปิดตัวตอนผลิตทีวีเครื่องนั้นเมื่อราว 10 ปีก่อน

  • เพิ่งเช็กดูและพบว่าฉันใช้ AdGuard ทั้งเครือข่าย บนทีวีมีคำขอถูกบล็อก 80% และทั้งเครือข่ายถูกบล็อกราว 50% มันบ้าสุด ๆ

  • ถ้า proxy แบบนี้ไม่ผิดกฎหมาย อย่างน้อยมันก็ควรจะผิดกฎหมาย แค่บอกว่ามันอยู่บนเส้นแบ่งของการเลี่ยงสมมติฐานพื้นฐานเรื่องการกำหนดเส้นทางอินเทอร์เน็ต การเช่า IP address และความเป็นเจ้าของ ก็ยังถือว่าเบาเกินไป เมื่อเทียบกับสิ่งที่ Bright Data เอามาห่อเป็นสินค้าที่ขายและรับเงินได้
    มีข้อความว่า “คุณอนุญาตให้ Bright Data ใช้ทรัพยากรส่วนเกินและ IP address ของอุปกรณ์ของคุณเพื่อดาวน์โหลดข้อมูลเว็บสาธารณะจากอินเทอร์เน็ต เป็นครั้งคราว”
    ส่วนที่ทำให้ผู้ใช้ปลายทางเข้าใจผิดคือคำว่า “ดาวน์โหลดข้อมูลเว็บสาธารณะ” ถ้าข้อมูลเป็นสาธารณะ แล้วทำไม Bright Data ถึงดาวน์โหลดเองไม่ได้? ก็คงเพราะอีกฝ่ายไม่ต้องการให้ทำ ผลิตภัณฑ์นี้คือการทำให้ผู้ใช้ช่วย Bright Data เลี่ยงคุณสมบัติที่ผู้ให้บริการข้อมูล “สาธารณะ” ไม่ต้องการให้มี แทนใครบางคนที่มีเงิน แต่เสียเปรียบอยู่บนอินเทอร์เน็ตด้วยเหตุผลที่สมควร
    มันน่ารังเกียจสิ้นดี แต่ก็พูดตามตรงว่าไม่ค่อยแปลกใจและไม่ค่อยกังวล เพราะรู้อยู่แล้วว่าทิศทางมันไหลไปแบบนี้ ผู้คนโหวตด้วยกระเป๋าสตางค์มานานแล้ว และคนที่ถูกใช้เป็น proxy ตรงนี้ไม่ใช่ Joe the Hacker สายใส่ใจความเป็นส่วนตัว แต่คือพ่อแม่ของพวกเราและคนนับล้านที่แค่อยากพักผ่อนหลังเลิกงาน รวมถึงพ่อแม่ที่มีลูกเล็ก
    ทุกวัน ทฤษฎีอินเทอร์เน็ตมืด ก็ดูเป็นไปได้มากขึ้น และพูดตามตรงฉันก็รู้สึกว่าไปทางนั้นก็ได้ อินเทอร์เน็ตจะพังทลายกลายเป็นเครือข่ายระหว่างเครือข่ายแบบศักดินาที่ไม่ว่าการกำหนดเส้นทางไหนก็ต้องใช้กุญแจทุก hop และแบบนั้นถึงจะพอรักษาความเชื่อถือบางส่วนไว้ให้กับคนจริง ๆ — และพูดตามตรงคือรวมถึงเอเจนต์ด้วย — ซึ่งตอนนี้กำลังถูกเลี่ยงอย่างแข็งขัน

    • มันถูกกฎหมายเต็ม ๆ และกฎหมายเกี่ยวกับ การกำหนดเส้นทาง IP และความเป็นเจ้าของที่อยู่ ที่พูดถึงนั้นไม่มีอยู่จริง

  • ปัญหาอย่างหนึ่งที่เห็นตรงนี้คือมันเหมือนกับตอนรัน Tor exit node ผู้ใช้ที่ไม่หวังดีสามารถใช้มันเพื่อซ่อนตำแหน่งของตัวเองได้
    ลองนึกภาพว่าคนร้ายตัวจริงคือคนที่ใช้ทีวีของคุณเป็น proxy เพื่อซื้อขายสื่อล่วงละเมิดทางเพศเด็ก แล้วตำรวจมาตามหาคุณที่บ้านเพราะคิดว่าคุณเป็นคนเผยแพร่

    • ฉันเกลียดจริง ๆ ที่ทุกอย่างกำลังกลายเป็นปฏิปักษ์ต่อผู้ใช้ เราต้องกลายเป็นผู้เชี่ยวชาญแทบทุกเรื่อง และต้องคอยตามข่าวตลอดเผื่อมีการเปลี่ยนแปลงใหญ่ที่ล้มสมมติฐานเดิม ๆ
      แล้วถ้าพลาดไปบ้างแล้วออกมาบ่น ก็จะมีกองทัพคนปกป้องโผล่มารีบแก้ต่าง เบี่ยงประเด็น หรือทำให้บทสนทนายุ่งเหยิง
      ข่าวดีนิดหน่อยคือความเหนื่อยล้าแบบนี้เริ่มไปถึงคนทั่วไปแล้ว เพื่อนร่วมงานของฉันบ่นว่าถ้าอยากตั้งข้อจำกัดและโควตาให้ลูก ๆ ได้อย่างถูกต้อง เขาต้องกลายเป็นผู้ดูแลไวไฟ/อินเทอร์เน็ตเต็มตัว
      ก็แค่ระบายความอัดอั้นน่ะ ตอนนี้ฉันยังไม่ค่อยรู้ว่าทางออกที่เหมาะสมที่นี่คืออะไร
    • กลุ่มอย่าง Bright Data มี กระบวนการยืนยันตัวลูกค้า ที่ค่อนข้างดี หลังจากโดนตำรวจมาเยี่ยมจนขวัญผวาไปพักใหญ่แล้ว คนก่อเหตุจริงก็คงได้เข้าคุก
 
GN⁺ 2026-06-07
ความเห็นจาก Lobste.rs

  • พอพูดถึงโปรโตคอลนี้แล้ว ก็อาจทำ reverse honeypot ที่คอยสมัครใจส่งข้อมูลขยะที่สุ่มสร้างขึ้นไปกับทุกคำขอ ซึ่งน่าจะเป็นโปรเจ็กต์ vibe coding สนุก ๆ สำหรับใครก็ตามที่มีโทเค็นเหลือ

    • ดูเหมือนไม่จำเป็นต้องลงมือทำโปรโตคอลนี้จริง ๆ ด้วยซ้ำ จาก log จะเห็นว่า residential proxy พวกนี้จำนวนมากปกปิดตัวเองได้ล้มเหลวอย่างสิ้นเชิง เลยสามารถปล่อยข้อมูลขยะกลับไปได้แบบง่าย ๆ
      ไม่ต้องใช้ vibe coding เลยด้วยซ้ำ และมีเครื่องมือที่ทำแบบนี้ได้อยู่แล้วเป็นสิบ ๆ ตัว หลายตัวในนั้นก็ส่งข้อมูลขยะแบบไม่รู้จบให้พร็อกซีพวกนี้มาเกิน 1 ปีแล้ว

  • ผมไม่เข้าใจเลยว่าทำไมต้องต่อ TV หรือเครื่องใช้ไฟฟ้าอื่น ๆ เข้ากับอินเทอร์เน็ต ไม่มีเหตุผลดี ๆ ที่ต้องทำแบบนั้น

    • คนดู บริการสตรีมมิง บน TV การต่อ TV เข้ากับอินเทอร์เน็ตคือวิธีที่ง่ายที่สุดในการทำแบบนั้น