เผยเทคนิคติดตามเว็บ-แอปแบบลับบน Android โดยใช้ Localhost
(localmess.github.io)- มีการเปิดเผยว่าแอปหลักอย่าง Meta (Facebook) และ Yandex ใช้พอร์ตภายในเครื่อง (127.0.0.1) บน Android เพื่อ แชร์ตัวระบุและคุกกี้ระหว่างเว็บเบราว์เซอร์กับแอปเนทีฟอย่างลับๆ
- สคริปต์ Facebook Pixel, Yandex Metrica ที่ฝังอยู่ในเว็บไซต์จะส่ง เซสชันการท่องเว็บและตัวระบุ จากเบราว์เซอร์ Android ไปยังแอปเนทีฟ (Facebook, Instagram และแอปในเครือ Yandex) โดยตรง ทำให้สามารถ ระบุตัวผู้ใช้ และ ยกเลิกการไม่ระบุตัวตน ได้
- วิธีนี้ หลบเลี่ยงมาตรการปกป้องความเป็นส่วนตัวแบบเดิมทั้งหมด เช่น การลบคุกกี้ โหมดไม่ระบุตัวตน การตั้งค่าสิทธิ์ และการรีเซ็ต Advertising ID และหากมีแอปอันตรายคอยฟังพอร์ตตรงกันอยู่ ก็ยังสามารถ เก็บประวัติการเข้าชมของเบราว์เซอร์ ได้ด้วย
- หลังจาก มีการเปิดเผยเมื่อ 3 มิถุนายน 2025 ฝั่ง Facebook ได้ลบโค้ดส่วนใหญ่ออกแล้ว แต่เทคนิคนี้ถูกใช้งานมาหลายปีบนอุปกรณ์ Android หลายร้อยล้านเครื่องทั่วโลก ขณะที่ Yandex ใช้วิธีคล้ายกันต่อเนื่องมาตั้งแต่ปี 2017
- เบราว์เซอร์หลักอย่าง Chrome, Firefox และ Brave ได้ออกมาตรการบล็อกฉุกเฉินแล้ว แต่ ข้อจำกัดเชิงโครงสร้างของแพลตฟอร์มทำให้ยังไม่มีวิธีแก้ที่สมบูรณ์ในระดับรากฐาน และมีการย้ำถึงความจำเป็นในการเสริมความปลอดภัยของ Android IPC และเครือข่ายภายในเครื่อง
Disclosure: เทคนิคติดตามเว็บ-แอปแบบลับผ่าน Localhost
- นักวิจัยพบว่า Meta และ Yandex ใช้วิธีที่ เจาะจงผู้ใช้ Android หลายพันล้านคน โดยให้แอปเนทีฟเปิดพอร์ตภายในเครื่องที่กำหนดไว้ล่วงหน้า (เช่น 12580~12585, 29009~30103) ไว้เบื้องหลัง แล้วสื่อสารกับ JavaScript ที่รันจากเว็บ
- ด้วยวิธีนี้ คุกกี้ เมทาดาทา และประวัติการใช้งานของเว็บเบราว์เซอร์ จะถูกส่งไปยังแอปเนทีฟ และนำไปรวมกับข้อมูลบัญชีในแอปและ Android Advertising ID ทำให้ เชื่อมโยงตัวตนของผู้ใช้เข้ากับการเข้าชมเว็บ ได้
How does this work?
การนำพอร์ตภายในเครื่องของ Android ไปใช้ในทางที่ผิด
- บน Android OS ทุกแอปสามารถเปิดซ็อกเก็ตบน 127.0.0.1 (loopback) ได้ หากมีเพียงสิทธิ์ INTERNET
- ตัวเบราว์เซอร์เองก็เข้าถึงอินเทอร์เฟซนี้ได้โดยไม่ต้องขอความยินยอมจากผู้ใช้เพิ่มเติม
- JavaScript ที่ฝังในเว็บไซต์สามารถ รับส่งข้อมูลระหว่างเบราว์เซอร์กับแอปเนทีฟได้ผ่าน Web API มาตรฐาน
วิธีเชื่อมต่อเว็บ-แอปของ Meta/Facebook Pixel
- เมื่อ JavaScript ของ Meta Pixel ถูกโหลดในเบราว์เซอร์ Android มันจะส่งค่าของ คุกกี้ _fbp ไปยังแอปเนทีฟผ่านแพ็กเก็ต STUN ของ WebRTC (UDP พอร์ต 12580–12585)
- แอป Facebook และ Instagram ในเครื่อง (เช่นเวอร์ชัน 515.0.0.23.90/382.0.0.43.84 เป็นต้น) จะรอฟังบนพอร์ตเหล่านั้น แล้วรับค่า _fbp จากเบราว์เซอร์เพื่อนำส่งต่อไปยังเซิร์ฟเวอร์ของตนผ่าน GraphQL
- _fbp เป็นคุกกี้หลักที่ฝังอยู่ในเว็บไซต์ยอดนิยมระดับท็อปล้านเว็บราว 25% เดิมทีติดตามข้ามเว็บไซต์ได้ยากเพราะแยกกันตามแต่ละเว็บ แต่ วิธีนี้ทำให้จับคู่ _fbp หลายค่าเข้ากับบัญชีผู้ใช้เดียวกันได้
- หลังเดือนพฤษภาคม 2025 มีการเพิ่มวิธี WebRTC TURN และปรับสคริปต์เพื่อหลีกเลี่ยงเทคนิค SDP Munging
- คุกกี้ _fbp มีอายุ 90 วัน และถูกใช้แพร่หลายมากจนพบในประมาณ 25% ของเว็บไซต์ยอดนิยม
- หลังเบราว์เซอร์หลักอย่าง Chrome ออกมาตรการตอบโต้ โค้ดดังกล่าวถูกลบเมื่อ 3 มิถุนายน
วิธีเชื่อมต่อเว็บ-แอปของ Yandex Metrica
- สคริปต์ Yandex Metrica ส่งคำขอผ่าน HTTP(S) ไปยังพอร์ตภายในเครื่อง (เช่น 29009, 29010, 30102, 30103) มาตั้งแต่ปี 2017
- แอปของ Yandex (เช่น Yandex Maps, Navigator, Browser, Search) จะเปิดพอร์ตค้างไว้ และตอบกลับคำขอด้วยข้อมูลที่มี Android Advertising ID (AAID), ตัวระบุอุปกรณ์อื่นๆ และ UUID ที่เข้ารหัสแบบ Base64
- จากนั้นสคริปต์ในเบราว์เซอร์จะเก็บข้อมูลนี้และส่งกลับไปยังเซิร์ฟเวอร์ของ Yandex ทำให้การเชื่อมโยงตัวระบุระหว่างเบราว์เซอร์-แอป-เซิร์ฟเวอร์สมบูรณ์
- โดเมน yandexmetrica.com ถูก resolve ไปยัง 127.0.0.1 เพื่อหลบเลี่ยงการตรวจจับและซ่อนกระบวนการเก็บข้อมูล
- เนื่องจาก ใช้ localhost ผ่าน HTTP หากมีแอปอื่นฟังพอร์ตเดียวกันอยู่ ก็อาจทำให้ประวัติการเข้าชมเว็บไซต์ของผู้ใช้รั่วไหลได้
ความเสี่ยงที่เกิดขึ้นจริง: ประวัติการเข้าชมจากเบราว์เซอร์รั่วไหล
- หากใช้การสื่อสารภายในเครื่องแบบ HTTP แอป Android ใดๆ ก็อาจดักรับ URL ที่ผู้ใช้เข้าชมและประวัติอื่นๆ ได้ เพียงแค่ฟังพอร์ตที่เกี่ยวข้อง
- นักวิจัยพัฒนาแอป Proof-of-Concept จริงและทดสอบกับ Chrome, Firefox และ Edge จนพิสูจน์ได้ว่า แม้แต่ Private Browsing และโหมด Incognito ก็ยังเปราะบางทั้งหมด
- มีเพียงบางเบราว์เซอร์ เช่น Brave และ DuckDuckGo ที่ป้องกันได้ด้วยบล็อกลิสต์ภายในและการบังคับขอความยินยอมจากผู้ใช้
Affected Sites
- Meta Pixel: ใช้งานบน 5.8 ล้านเว็บไซต์ จากการครอว์ลจริงพบการแชร์ local ID บนเว็บไซต์ 100,000 อันดับแรก โดยพบในสหภาพยุโรป 15,000 เว็บไซต์ และในสหรัฐฯ 17,000 เว็บไซต์
- Yandex Metrica: ใช้งานบน 3 ล้านเว็บไซต์ และพบการสื่อสารผ่าน local port แบบเดียวกันในสหภาพยุโรป 1,260 เว็บไซต์ และในสหรัฐฯ 1,312 เว็บไซต์
- เว็บไซต์จำนวนมากในกลุ่มนี้ เริ่มติดตามผู้ใช้โดยอัตโนมัติแม้ไม่มีขั้นตอนขอความยินยอมต่อคุกกี้
History
- Yandex: เริ่มใช้พอร์ต HTTP/HTTPS ตั้งแต่ปี 2017
- Meta: เริ่มจาก HTTP ในเดือนกันยายน 2024, WebSocket ในเดือนพฤศจิกายน 2024, WebRTC STUN ในปี 2025 และเปลี่ยนเป็น TURN ในเดือนพฤษภาคม
Abuse Vectors
- สาเหตุหลักคือ Android ไม่มีข้อจำกัดในการเข้าถึงซ็อกเก็ต localhost และนโยบาย sandbox ยังไม่เพียงพอ
- หลบเลี่ยงมาตรการป้องกันทั้งหมด ไม่ว่าจะเป็นการตั้งค่าสิทธิ์เดิม โหมดไม่ระบุตัวตนของเบราว์เซอร์ หรือการรีเซ็ต Advertising ID
- แม้จะแยกจากการใช้งานที่ถูกต้องตามกฎหมายเพื่อการพัฒนาเว็บได้ยาก แต่กรณีนี้เป็นตัวอย่างยืนยันการติดตามขนาดใหญ่ในโลกจริง
- เบราว์เซอร์อย่าง Chrome, Firefox, DuckDuckGo และ Brave กำลังออกแพตช์ตอบสนองฉุกเฉิน แต่ในระยะยาวยังจำเป็นต้องมี การเสริมสิทธิ์ คำเตือน sandbox และนโยบาย IPC ในระดับแพลตฟอร์ม
Disclosure
- มีการร้องขอ การเปิดเผยอย่างรับผิดชอบและความร่วมมือ ไปยังผู้ให้บริการเบราว์เซอร์อย่าง Chrome, Firefox, DuckDuckGo และ Brave
- มีการออกมาตรการระยะสั้นแล้ว เช่น Chrome (เวอร์ชัน 137), Firefox (เวอร์ชัน 138), Brave เป็นต้น โดย บล็อกพอร์ตที่เสี่ยงและบล็อก SDP Munging
- ในระยะยาว มีการย้ำถึงความจำเป็นของการปรับปรุงเชิงโครงสร้าง เช่น การควบคุมการเข้าถึงเครือข่ายภายในเครื่อง การเสริม sandbox และการแจ้งเตือนผู้ใช้
| เบราว์เซอร์ | เวอร์ชัน | Yandex | สถานะการตอบสนอง/การบล็อก | |
|---|---|---|---|---|
| Chrome | 136.0+ | ได้รับผลกระทบ | ได้รับผลกระทบ | ตั้งแต่ 137 มีการบล็อกพอร์ตและ SDP munging และกำลังทยอยใช้งาน |
| Edge | 136.0+ | ได้รับผลกระทบ | ได้รับผลกระทบ | ยังไม่ชัดเจน (อิง Chromium) |
| Firefox | 138.0.2 | ได้รับผลกระทบ | ไม่ได้รับผลกระทบ(1) | บล็อก SDP munging แล้ว ส่วน UDP จะบล็อกในภายหลัง |
| DuckDuckGo | 5.233.0 | ได้รับผลกระทบบางส่วน(2,3) | ไม่ได้รับผลกระทบ(2,3) | บล็อกโดยอิงบล็อกลิสต์ |
| Brave | 1.78.102 | ไม่ได้รับผลกระทบ(3,4) | ไม่ได้รับผลกระทบ(3,4) | ตั้งแต่ปี 2022 ต้องขอความยินยอมจากผู้ใช้ก่อนส่งคำขอไป localhost และใช้บล็อกลิสต์ |
- 1: บล็อก SDP Munging แล้ว แต่ยังไม่บล็อก TURN port (มีแผนเพิ่มภายหลัง)
- 2,3,4: ใช้การป้องกันหลายแบบ เช่น บล็อกลิสต์ การบล็อกพอร์ต และการขอความยินยอมจากผู้ใช้
สถานะการรับรู้ของผู้ใช้และผู้ดูแลระบบ
ผู้ดูแลเว็บไซต์
- เอกสารทางการของ Meta และ Yandex ไม่เคยเปิดเผยวิธีนี้
- ตั้งแต่เดือนกันยายน 2024 เป็นต้นมา มีคำถามตามฟอรัมสำหรับนักพัฒนา Facebook อย่างต่อเนื่องว่า "ทำไมสคริปต์ Pixel ถึงเข้าถึง localhost" แต่ไม่มีคำตอบทางการ
- ผู้ดูแลเว็บไซต์และผู้ใช้ปลายทางส่วนใหญ่ไม่รับรู้เรื่องนี้ และผู้ใช้ยังถูกติดตามได้แม้อยู่ในสถานะ ไม่ได้ล็อกอิน ใช้โหมดไม่ระบุตัวตน หรือลบคุกกี้แล้ว
ผู้ใช้ทั่วไป
- การติดตามทำงานได้ ไม่ว่าผู้ใช้จะล็อกอินอยู่หรือไม่ก็ตาม
- มาตรการอย่างโหมดไม่ระบุตัวตนและการลบคุกกี้ถูกทำให้ไร้ผล
- มีหลายกรณีที่ ทำงานได้แม้บนเว็บไซต์ที่ไม่มีขั้นตอนขอความยินยอมต่อคุกกี้
FAQ สรุป
- Q: ทำไม Meta ถึงหยุดใช้วิธีนี้ทันทีหลังถูกเปิดเผย?
A: ไม่มีคำชี้แจงทางการ แต่ยืนยันได้ว่าหลังการเปิดเผยมีการหยุดส่งแพ็กเก็ตไปยังผู้ใช้ Android แล้ว - Q: งานวิจัยนี้ผ่าน peer review แล้วหรือยัง?
A: มีบางสถาบันช่วยตรวจสอบแล้ว แต่ยังไม่ผ่านการพิจารณาบทความวิชาการ และตัดสินใจเปิดเผยอย่างรวดเร็วเพราะขนาดของการใช้งานในทางที่อาจเป็นอันตราย - Q: มีระบุไว้ในเอกสารทางการของ Meta/Yandex หรือไม่?
A: ไม่มีเอกสารทางเทคนิคอย่างเป็นทางการ มีเพียงคำถามในฟอรัมนักพัฒนา - Q: iOS หรือแพลตฟอร์มอื่นได้รับผลกระทบด้วยหรือไม่?
A: เท่าที่ตรวจพบในตอนนี้พบเฉพาะบน Android แต่ในทางเทคนิค iOS/เดสก์ท็อป/สมาร์ททีวี ก็อาจมีความเสี่ยงได้เช่นกัน
11 ความคิดเห็น
ก่อนหน้านี้รู้สึกว่าแบตหมดไวผิดปกติเลยลบแอปฝั่ง Meta ออกหมดแล้ว ที่แท้ก็มีเรื่องแบบนี้นี่เอง... สงสัยคงต้องลบแอประบบที่ติดมากับ Galaxy ที่เหลือออกให้หมดด้วยผ่าน
adbผมก็ไม่ไว้ใจแอปของ Meta เหมือนกันเลยไม่ใช้ และเลือกใช้ผ่าน Chrome ใน Secure Folder เท่านั้น
เฟรมเวิร์กประเภทที่เรียกว่าไฮบริดเว็บแอปส่วนใหญ่จะเปิดเว็บเซิร์ฟเวอร์
localhostไว้ (แม้จุดประสงค์จะต่างกัน) สิ่งที่แก้ไม่ได้ด้วยการตั้งค่าไลบรารีเบราว์เซอร์แบบฝังตัว (WebKit...) หรือการคัสตอมเอง (ฝั่งเว็บ) ก็ไปแก้จากฝั่งเว็บเซิร์ฟเวอร์ที่รันบนlocalhost(ฝั่งเนทีฟ) แทนได้ และปรากฏว่ายังเอามาใช้แบบนี้ได้ด้วย... น่าเสียดายจริงๆผมคิดว่าวิธีสื่อสารทั่วไประหว่างเว็บกับแอปในไฮบริดแอปคือการใช้ API ที่ฝั่ง OS และเบราว์เซอร์มีให้ ซึ่งมักเรียกว่า bridge ครับ ผมมองว่า local web server ไม่ใช่สิ่งจำเป็น
สาเหตุที่การใช้ local web server ตรงนั้นกลายเป็นปัญหา น่าจะเป็นเพราะมันเปิดช่องให้เกิดช่องโหว่แบบที่สามารถเข้าถึงพอร์ต localhost จาก Chrome โหมดไม่ระบุตัวตน แล้วทำลายความเป็นนิรนามของผู้ใช้ได้ เป็นต้น ถ้าเทคโนโลยีแบบนี้เป็นสิ่งจำเป็นสำหรับไฮบริดแอปจริง ๆ .. ไฮบริดแอปก็ควรหายไปเสียเถอะครับ
โดยทั่วไปมักจะเปิดเว็บเซิร์ฟเวอร์ภายในแอปเพื่อใช้งาน สำหรับจัดการฟีเจอร์ที่บังคับให้ต้องมีโดเมนเนม รวมถึง
localStorageเป็นต้นถ้าคุณไม่ได้จ่ายเงินให้บริการ ก็แปลว่าตัวคุณเองคือสินค้า ยิ่งนับวันความพยายามในการติดตามตัวบุคคลผ่านข้อมูลก็จะยิ่งเพิ่มมากขึ้น และดูไม่ออกเลยว่าจะย้อนกระแสนี้กลับไปได้อย่างไร เราต้องการทางเลือกที่ดีกว่านี้ แต่ภายใต้ระบบทุนนิยมก็นึกไม่ค่อยออกเหมือนกันว่าทางเลือกที่ดีกว่านั้นจะเป็นอะไร
สงสัยว่าการเข้าถึง localhost จากภายในและภายนอก Secure Folder ของ Galaxy ถูกแยกออกจากกันหรือไม่
เหมือนจะไม่ได้แยกกันนะครับ ลองรัน Python
http.serverด้วย Termux นอก Secure Folder แล้วเข้าใช้งานจาก Chrome ข้างใน ก็ยังเชื่อมต่อได้นี่ไม่ใช่ช่องโหว่ด้านความปลอดภัยเหรอ -_-??
ดูเหมือนว่าคำตอบที่ถูกต้องคือไม่เล่นโซเชียลมีเดีย..
ความคิดเห็นบน Hacker News
ถ้าสรุปกระบวนการติดตามทั้งหมดที่ Meta ใช้ตามความเข้าใจของผม โดยอ้างอิงจาก บล็อก Localmess จะได้ประมาณนี้
แม้อยู่ในโหมดไม่ระบุตัวตนก็ยังติดตามได้
_fbp(ซึ่งมีข้อมูลการท่องเว็บอยู่) ไปยังแอป Instagram หรือ Facebook โดยใช้เทคนิค WebRTC (STUN) SDP Mungingกระบวนการนี้เป็นส่วนที่มองไม่เห็นแม้แต่ในเครื่องมือนักพัฒนาของเบราว์เซอร์
แอปจะส่งข้อมูล
_fbpและ user ID ไปยังเซิร์ฟเวอร์ของ Metaประเด็นที่น่าสังเกตเพิ่มเติมคือ
วิธีแชร์ ID จากเว็บไปยังแอปแบบนี้หลบเลี่ยงมาตรการคุ้มครองความเป็นส่วนตัวทั่วไป เช่น การลบคุกกี้ โหมดไม่ระบุตัวตน และการควบคุมสิทธิ์ของ Android
แถมยังเปิดช่องให้แอปอันตรายแอบสอดแนมกิจกรรมบนเว็บของผู้ใช้ได้ด้วย
หลังกลางเดือนพฤษภาคม สคริปต์ Meta Pixel เริ่มส่งคุกกี้
_fbpผ่านวิธี WebRTC TURN ด้วย ซึ่งเป็นวิธีที่นำมาใช้หลังทีม Chrome บล็อก SDP Mungingณ วันที่ 2 มิถุนายน 2025 ยังไม่พบพฤติกรรมที่แอป Facebook/Instagram รับข้อมูลจริงผ่านพอร์ตใหม่ดังกล่าว
ถ้ากรณีใช้งานหลักของ WebRTC คือการดึงข้อมูลอย่าง IP ภายในเครื่องของผู้ใช้เพื่อยกเลิกความไม่ระบุตัวตน ก็ไม่เข้าใจว่าทำไมฟีเจอร์แบบนี้ถึงทำงานได้โดยไม่ต้องขอสิทธิ์แยกต่างหาก
ในบางประเทศ การเข้าเว็บไซต์อย่าง something-embarassing.com อาจไม่ได้แค่น่าอาย แต่เสี่ยงต่อผลลัพธ์ที่ร้ายแรงกว่านั้นมาก
ยังไม่เข้าใจทั้งหมดนัก แต่ก็สงสัยว่านี่อาจรวมถึงการฉวยใช้ประกาศขอความยินยอมคุกกี้ตาม GDPR ที่จำเป็น เพื่อแอบติดตามคนอย่างลับๆ ด้วยหรือเปล่า
อยากแบนโฆษณาและการติดตามบนอินเทอร์เน็ตไปเลย
ของไร้สาระมันล้นออกมาก็เพราะเรื่องพวกนี้
มองว่าเป็นปัญหาที่เกิดขึ้นเพราะ CEO อยากได้เรือยอชต์เพิ่มอีกลำ
Reddit เองก็เก็บ fingerprint ของอุปกรณ์เยอะมากเหมือนกัน
ตอนนี้ยังขายข้อมูลเหล่านี้ไปใช้ฝึกโมเดล AI ด้วย
คาดว่าอีกไม่นานคงถึงวันที่เอาข้อมูลปิดที่ใช้ได้เฉพาะในแอประดับพรีเมียมไปขายอย่างจริงจังด้วย
ยังเหลือคำถามว่าจะสั่งห้ามเรื่องนี้อย่างไร และจะพิสูจน์ได้อย่างไรว่าใครเป็นคนละเมิดกฎหมายนั้น
ความพยายามผลักดันให้เบราว์เซอร์เลิกใช้ 3rd-party cookies เป็นก้าวแรกที่เป็นไปได้จริงที่สุด
แต่ Google ใช้อำนาจครอบงำของ Chrome ทำให้เรื่องนี้ล้มไปเมื่อปีที่แล้ว
ทางกฎหมายอาจไม่มีปัญหา แต่เป็นการบิดเบือนตลาดที่ไร้จริยธรรมและควรทำให้ผู้บริโภคโกรธ
ดูเหมือนผู้บริหาร Google ตอนแรกจะเชื่อว่ารักษารายได้ไว้ได้โดยไม่ต้องพึ่งคุกกี้ ทั้งที่จริงอาจไม่เข้าใจความหมายของคุกกี้เลย หรือไม่ก็ไม่เคยคิดจะเอาออกตั้งแต่แรก
พฤติกรรมแบบนี้เป็นความโลภล้วนๆ
นักบริหารแบบดั้งเดิมที่ประสบความสำเร็จมาหลายศตวรรษหลีกเลี่ยงความหมกมุ่นกับผลประโยชน์ส่วนตัวเกินควรแบบนี้
แม้แต่ผู้นำระดับกลางๆ โดยทั่วไปก็ยังพาบริษัทไปได้ดีกว่าโดยไม่ทำตัวต่ำแบบนี้
แต่ในโลกที่เหลือแต่ความโลภ ก็คงได้แต่หัวเราะขำๆ ไป
ถ้ามี CEO ที่ทั้งซื่อตรงและเก่งกว่านี้ก็คงดี
เสริมมุก 'เรือยอชต์ของ CEO' ว่าจริงๆ แล้วผู้บริโภคส่วนใหญ่ชอบบริการ/ผลิตภัณฑ์ที่ใช้ฟรีได้ เลยเลือกโมเดลโฆษณา
ถ้ามีทั้งแบบเสียเงินกับแบบมีโฆษณา เวอร์ชันที่มีโฆษณามักนิยมกว่าประมาณ 10:1
การบล็อกโฆษณากลับยิ่งทำให้สถานการณ์แย่ลง — การต่อต้านที่แท้จริงควรเป็นการเลิกใช้บริการหรือจ่ายเงินให้ทางเลือกอื่นโดยตรง
คิดว่าโครงสร้างอย่าง BAT (Brave Attention Token) ที่กระจายไมโครเพย์เมนต์ให้เว็บไซต์โดยตรงสมเหตุสมผลกว่า
แนวคิดในทางทฤษฎีคือ: จ่ายตามที่ใช้ และผมเป็นลูกค้าตัวจริง ไม่ใช่ผู้โฆษณา
รายงานประเด็นจริง: บล็อก Localmess
Google บอกว่ากำลังตรวจสอบการใช้งานในทางที่ผิด แต่ในอีกด้านหนึ่ง Google เองก็ติดตามทุกคนผ่าน side channel หลายแบบ เช่น ชื่อ Wi‑Fi AP
บริษัทแอปรายใหญ่ยังคงเก็บข้อมูลด้วยวิธีคล้ายกันเพื่อเลี่ยงข้อจำกัดของ OS
อีกเหตุผลหนึ่งที่ไม่ควรติดตั้งแอปของบิ๊กเทคถ้าเลี่ยงได้ และใช้แค่เว็บไซต์เมื่อจำเป็นจริงๆ
เว็บไซต์อาจช้าและใช้งานไม่สะดวก แต่ปลอดภัยกว่ามากเพราะอยู่ใน sandbox
เช่น โทรศัพท์ Samsung มักติดตั้งแอป Meta หลายตัวมาแต่แรก และแม้ลบแอป Facebook ไปแล้วก็อาจยังเหลือบริการซ่อนอย่าง com.facebook.services
บริการพวกนี้ลบได้ผ่านเครื่องมือนักพัฒนา (ADB/UAD) เท่านั้น
ไม่อย่างนั้นก็แนะนำให้ใช้ iPhone หรือ Pixel
ข้อมูลเชิงเทคนิคเกี่ยวกับสคริปต์ Meta Pixel:
Meta Pixel ส่งข้อมูลผ่าน HTTP จนถึงเดือนตุลาคม 2024 และแอป Facebook/Instagram ก็ยังคงรอฟังอยู่ที่พอร์ตนั้นในปัจจุบัน
ยังรอฟังอยู่ที่พอร์ตใหม่ 12388 ด้วย แต่ยังไม่พบสคริปต์ที่ส่งข้อมูลไปยังพอร์ตนั้น
เรื่องนี้เลยทำให้อยากรู้อย่างเชิงวิทยาศาสตร์(?) ว่าถ้ามีแอปอื่นส่งข้อความปลอมไปที่พอร์ตนี้จะได้ไหม
วิธีหนึ่งคือไม่ส่งอะไรเลย และอีกวิธีคือส่งข้อมูลปลอมจำนวนมาก
คิดว่าน่าจะดีถ้ามีอุปกรณ์ที่แชร์คุกกี้ติดตามโฆษณาผ่าน P2P ได้
สงสัยว่าการติดตามนี้ข้ามระหว่างโปรไฟล์ได้ไหม
ถ้าได้ ในมุมขององค์กรนี่ถือเป็นประเด็นความปลอดภัยใหญ่มาก
ลองทดสอบโดยเปิดเซิร์ฟเวอร์บนพอร์ต 8080 จากแอป Userland แล้วพบว่าทั้งสองโปรไฟล์เข้าถึงได้
นั่นหมายความว่าแอปที่ติดมัลแวร์ในโปรไฟล์หนึ่งอาจรับส่งข้อมูลกับเว็บไซต์ที่เปิดในอีกโปรไฟล์ได้
ถ้าบุคคลทั่วไปเก็บข้อมูลจากคอมพิวเตอร์ของคนอื่นด้วยวิธีแบบนี้ จะเข้าข่ายถูกลงโทษตาม CFAA (Computer Fraud and Abuse Act) หรือไม่
วิธีนี้ต้องควบคุมโค้ดทั้งสองฝั่ง คือฝั่งเว็บไซต์ที่กำลังเข้าชม และฝั่งแอปที่รันอยู่บนโทรศัพท์
มันไม่ใช่เทคนิคแฮ็กที่ขโมยประวัติเบราว์เซอร์แบบสุ่มได้ราวกับเวทมนตร์
เพราะงั้นจึงยากจะมองว่าเป็นการแฮ็กอย่างชัดเจน และแม้ Google/Meta จะติดตามโดยไม่ได้รับความยินยอม ก็ไม่น่าเข้าข่าย CFAA
ที่จริงมีคนเคยถูกดำเนินคดีตาม CFAA เพียงเพราะกด 'ดูซอร์สของหน้าเว็บ' ในเบราว์เซอร์ด้วยซ้ำ
ดูเหมือนว่าสิ่งสำคัญไม่ใช่ตัวการกระทำว่าเป็นอาชญากรรมแค่ไหน แต่เป็นไปโดนใครและเกี่ยวกับเครือข่ายไหนมากกว่า
มีโอกาสถูกลงโทษได้
ระบบ ID นี้เปิดช่องให้ถูกใช้ในทางที่ผิดได้ง่ายเกินไป และคาดว่า Google ก็น่าจะรู้เรื่องนี้พร้อมเข้าใจว่าต้องมีข้อกำหนดป้องกันการใช้งานผิดแน่นอน
เป็นปัญหาที่อาจนำไปสู่บทลงโทษได้ถึงขั้นแบนถาวรจาก Play Store การดำเนินคดีทางกฎหมาย หรือแม้แต่คดีอาญา
แต่ในโลกความจริง ถ้าเป็นบริษัทขนาดใหญ่ระดับ Meta ก็แทบเป็นไปไม่ได้ที่จะมีการลงโทษอย่างมีนัยสำคัญ
(และถึงจะไม่ใช่ Meta ก็ยังอาจเป็นไปได้ว่าหน่วยข่าวกรองหรือหน่วยงานบังคับใช้กฎหมายอนุมัติพฤติกรรมชวนสงสัยแบบนี้โดยปริยาย — มันยากมากที่จะหยุดปัญหา และไม่ง่ายแม้แต่จะพูดถึงมัน)
พวกเขามีวิธีติดตามกันเองมากกว่า 50 แบบ
บริษัทอื่นๆ ก็ทำเงินก้อนโตจากการเจรจาเงื่อนไขการแบ่งปันข้อมูลผู้ใช้กับบริษัทใหญ่ใหม่อีกด้วย
ดีลก็ทำกันเรียบร้อย ได้สิทธิ์กันครบแล้ว ที่มีอยู่ก็แค่ผู้ใช้บางส่วนออกมาโวยวายเรื่องนี้เท่านั้น
ใน Firefox สามารถบล็อก WebRTC ได้โดยไปที่ about:config แล้วตั้งค่า
media.peerconnection.enabledเป็นfalseหากใช้ Netguard ร่วมกับ Nebulo ในโหมด non-VPN ก็สามารถบล็อกการเชื่อมต่อที่ไม่จำเป็นไปยังเซิร์ฟเวอร์ของ Meta ได้
คิดว่าสหภาพยุโรป (EU) ควรปรับเรื่องแบบนี้ในระดับทำลายสถิติ
และน่าจะออกภาษีแบบขั้นบันไดเพิ่มขึ้น 1~X% ทุกครั้งที่ทำผิดซ้ำ
พร้อมทั้งควรมีเว็บไซต์ที่ดูกรณีละเมิดของแต่ละบริษัทได้ในที่เดียว
Meta ยังทำกำไรสุทธิได้ราว 7 หมื่นล้านดอลลาร์ต่อปีแม้จะโดนปรับทุกปี
ไม่ใช่แค่ค่าปรับเท่านั้น บางกรณียังควรมีมาตรการที่แรงกว่านี้ เพราะคนทั่วไปบางคนยังติดคุกจากความผิดที่เบากว่านี้มาก