Facebook ดักจับทราฟฟิกแอปมือถือที่เข้ารหัสของคู่แข่งได้อย่างไร
(doubleagent.net)- จากเอกสารสาธารณะในคดีฟ้องร้องแบบกลุ่มด้านการผูกขาดต่อ Meta และการย้อนวิศวกรรม Onavo Protect Android APK ที่ถูกเก็บถาวรไว้ ทำให้เห็นโครงสร้างที่ Facebook สามารถถอดรหัสทราฟฟิก HTTPS ของแอปคู่แข่งด้วยวิธีคนกลางดักฟังได้
- แกนสำคัญคือการให้ติดตั้ง ใบรับรอง CA ของ Facebook Research ลงบนอุปกรณ์ จากนั้นเชื่อมทราฟฟิกของ Onavo VPN ไปยัง
ssl bumpของพร็อกซีโปร่งใส Squid บนโครงสร้างพื้นฐานของ Facebook - Onavo Protect ถูกติดตั้งบน Android มากกว่า 10 ล้านครั้ง และในรุ่นที่แจกจ่ายปี 2016 มีการบรรจุใบรับรอง CA ไว้ในทรัพยากรของแอป โดยหนึ่งในนั้นมีอายุใช้งานถึงปี 2027
- หลัง Android 7 เป็นต้นมา การเชื่อถือ CA ที่ผู้ใช้เพิ่มเองและขั้นตอนติดตั้งใบรับรองถูกจำกัด ทำให้ประสิทธิภาพลดลง แต่ในเวลานั้น
sc-analytics.appspot.comของ Snapchat ถูกยืนยันว่าเป็นกรณีที่สามารถทำ MITM ได้เพราะไม่มี certificate pinning - หลัง Android เพิ่มความปลอดภัยและมีการใช้ pinning มากขึ้น Facebook ถึงขั้นพิจารณาใช้ Accessibility API และชุดสิทธิ์ของ Onavo ก็ยังเปิดโอกาสให้เข้าถึงข้อมูลอ่อนไหวอย่าง IMSI ได้ด้วย
โครงสร้างของ Onavo ที่ยืนยันได้จากเอกสารสาธารณะและการย้อนวิศวกรรม APK
- เอกสารสาธารณะในคดีแบบกลุ่มที่กำลังดำเนินอยู่กับ Meta มีข้อมูลที่อาจชี้ว่า Facebook ละเมิด Wiretap Act
- ตามคำอธิบายของผู้ใช้ HN ตัวคดีนี้เองไม่ใช่คดีดักฟัง แต่เป็นคดีผูกขาดภายใต้ Sherman Act และทีมทนายฝ่ายโจทก์พบความเป็นไปได้ที่เกี่ยวข้องกับ Wiretap Act โดยบังเอิญระหว่างกระบวนการเปิดเผยหลักฐาน
- พื้นฐานของการวิเคราะห์คือเอกสารศาลที่เปิดเผยต่อสาธารณะและการย้อนวิศวกรรม แพ็กเกจแอป Android ของ Onavo Protect ที่ถูกเก็บถาวรไว้
- ข้อมูลที่เปิดเผยมีจำกัดและเป็นเพียงบางส่วน จึงอาจมีข้อเท็จจริงบางอย่างที่ไม่ถูกต้องหรือไม่ครบถ้วน
- ยังไม่ชัดเจนว่าทราฟฟิกของผู้ใช้แอปทั้งหมดถูกดักจับหรือมีเพียงผู้ใช้บางส่วนเท่านั้น
วิธีถอดรหัสทราฟฟิก HTTPS บางส่วนด้วย ssl bump
- Facebook เรียกเทคนิคนี้ว่า
ssl bumpและชื่อนี้มาจากความสามารถของพร็อกซีโปร่งใสใน Squid caching proxy - ลำดับการทำงานใกล้เคียงกับองค์ประกอบต่อไปนี้
- ติดตั้งใบรับรองที่เชื่อถือได้ซึ่งออกโดย Facebook Research ลงบนอุปกรณ์
- ส่งทราฟฟิกของอุปกรณ์ผ่าน Onavo VPN ไปยังโครงสร้างพื้นฐานที่ Facebook ควบคุม
- เปลี่ยนเส้นทางทราฟฟิกไปยังพร็อกซีโปร่งใสของ Squid
- ใช้การตั้งค่า
ssl bumpเพื่อถอดรหัสทราฟฟิก TLS ของโดเมนบางรายการ
- จากเอกสารศาล โดเมนที่สนใจได้แก่โดเมนที่เกี่ยวข้องกับ Snapchat, Amazon และ YouTube
- จากแอป Onavo ที่ถูกเก็บถาวรเพียงอย่างเดียว ยังยากที่จะยืนยันว่าทราฟฟิกของผู้ใช้รายอื่นถูกดักจับจริงหรือเพียงแค่ผ่านพร็อกซีเท่านั้น
สิทธิ์และความสามารถในการเก็บข้อมูลของแอป Onavo Protect
- แอป Onavo Protect บน Android ถูกติดตั้งมากกว่า 10 ล้านครั้ง และมีโค้ดที่ชักจูงให้ผู้ใช้ติดตั้ง ใบรับรอง CA ลงในที่เก็บใบรับรองที่ผู้ใช้เชื่อถือบนอุปกรณ์
- แอปอ้างเหตุผลเรื่อง “การปกป้อง” และการแสดงปริมาณการใช้ข้อมูลเพื่อขอสิทธิ์หลายอย่าง
Display over other appsAccess past and deleted app usage
- ใน Android manifest มี
android.permission.PACKAGE_USAGE_STATSอยู่ด้วย ซึ่งทำให้สามารถเก็บสถิติการใช้งานและปริมาณการใช้เครือข่ายของแอปอื่นได้ - ในสคีมาฐานข้อมูลภายในเครื่อง ดูเหมือนมีการเก็บข้อมูลระดับค่อนข้างสูง เช่น สถิติการใช้งานแอปและปริมาณทราฟฟิกเครือข่ายแยกตามแอป
- อีเมลในเอกสารสาธารณะมีทั้งความต้องการ “reliable analytics” สำหรับ Snapchat และแนวคิดเรื่อง “kit สำหรับ iOS และ Android ที่ดักจับทราฟฟิกของซับโดเมนเฉพาะ”
การติดตั้งใบรับรอง CA และการเปลี่ยนแปลงด้านความปลอดภัยของ Android
- ในแอป Onavo มีฟังก์ชันเรียก
KeyChain.createInstallIntent()ของ Android เพื่อติดตั้งใบรับรอง และจะมีป๊อปอัปให้ผู้ใช้ติดตั้งในชื่อ Facebook Research KeyChain.createInstallIntent()ไม่ได้ทำงานแบบเดิมอีกต่อไปตั้งแต่ Android 7 Nougat- นโยบายความปลอดภัยของ Android ก็เปลี่ยนไปอย่างมากหลังจากนั้น
- แอปที่กำหนดเป้าหมาย Android 6.0 API level 23 หรือต่ำกว่า จะเชื่อถือที่เก็บ CA ที่ผู้ใช้เพิ่มเองโดยปริยาย
- ตั้งแต่ Android 7 เป็นต้นมา แอปจะไม่เชื่อถือ CA ที่ผู้ใช้เพิ่มเองโดยปริยาย เว้นแต่จะตั้งค่าความปลอดภัยแยกไว้
- ใน Android 7 จะไม่สามารถติดตั้งใบรับรองลงในที่เก็บระบบได้โดยไม่รูตเครื่อง
- Android 11 ปิดกั้นกลไกที่แอปใช้ชักจูงผู้ใช้ไปติดตั้งใบรับรองอย่างสมบูรณ์ และไม่มีแอปใดเชื่อถือใบรับรองในที่เก็บของผู้ใช้โดยปริยายอีกต่อไป
- วิธีที่เคยทำได้ในช่วงปี 2016~2019 จึงยากที่จะทำซ้ำในสภาพแวดล้อม Android ปัจจุบันในเชิงเทคนิค
ใบรับรอง Facebook Research ที่รวมอยู่ในแอป
- ใน Onavo APK เวอร์ชันเดือนกันยายน 2017 มี
old_ca.cerและnew_ca.cerอยู่ในโฟลเดอร์assets - โค้ดที่เกี่ยวข้องพบได้ในคลาส
ResearchCertificateManager - ความต่างของใบรับรองทั้งสองคือระยะเวลาที่มีผล
- ใบรับรองแรกมีผลตั้งแต่ 8 กันยายน 2016 และมีอายุ 1 ปี
- ใบรับรองที่สองมีผลตั้งแต่ 8 มิถุนายน 2017 ถึง 8 มิถุนายน 2027
- ในเอกสารศาลมีข้อความว่าระบุว่าใบรับรองที่ใช้กับ SSL bump “ถูกสร้างบนเซิร์ฟเวอร์และส่งไปยังอุปกรณ์”
- ในแอปที่ตรวจสอบได้ ยังไม่พบฟังก์ชันที่ชัดเจนว่ามีการเพิ่มใบรับรองจากเซิร์ฟเวอร์หลังปี 2017 จึงยังต้องตรวจสอบเพิ่มเติม
โดเมนวิเคราะห์ของ Snapchat และ certificate pinning
- หากเป็นแอปที่ใช้ certificate pinning อย่างสมบูรณ์ วิธี MITM นี้ก็คงใช้งานไม่ได้
- ในหลักฐานที่เปิดเผยต่อสาธารณะ มีโดเมนที่เกี่ยวข้องกับ Snapchat คือ
sc-analytics.appspot.com - จากการถอดแอป Snapchat รุ่นเก่า พบว่าทราฟฟิกไปยังโดเมนวิเคราะห์ดังกล่าวไม่ได้ใช้ certificate pinning
- Facebook รับรู้ว่าการเพิ่มความปลอดภัยของ Android และการแพร่หลายของ certificate pinning ทำให้ความเป็นไปได้ในการใช้
ssl bumpระยะยาวลดลง
การพิจารณาใช้ Accessibility API และการเข้าถึงข้อมูลอ่อนไหว
- เมื่อ Android เพิ่มความปลอดภัยและมีการใช้ certificate pinning อย่างแพร่หลาย Facebook จึงพิจารณาใช้ Accessibility API เป็นทางเลือก
- Google ระบุว่าเครื่องมือด้านการเข้าถึงสามารถประกาศเป็นบริการช่วยการเข้าถึงได้เฉพาะกรณีที่ช่วยให้ผู้พิการใช้อุปกรณ์หรือเอาชนะข้อจำกัดจากความพิการเท่านั้น
- การนำฟีเจอร์การเข้าถึงของ Android ไปใช้ผิดวัตถุประสงค์ มักเชื่อมโยงกับกรณีแอปอันตรายอย่าง banking malware
- ใน manifest ของแอป Onavo มีสิทธิ์
READ_PHONE_STATEอยู่ และในเวลานั้นสิทธิ์นี้สามารถใช้เข้าถึงข้อมูลอ่อนไหวอย่าง subscriber IMSI ได้ - ความเป็นไปได้ในการเข้าถึง IMSI แสดงให้เห็นว่ายังควรตรวจสอบเพิ่มเติมว่ามีข้อมูลอื่นใดที่แอป Onavo อาจเก็บรวบรวมได้อีก
ความต่างจากประเด็นอื้อฉาว Onavo ก่อนหน้านี้
- ข้อมูลเกี่ยวกับ MITM ครั้งนี้เป็นคนละประเด็นกับข้อถกเถียงเรื่อง Facebook Project Atlas และ Onavo ที่เป็นข่าวในปี 2019
- ในปี 2019 แอป Onavo ถูกถอดออกจากแอปสโตร์หลังมีการตรวจสอบว่า Facebook จ่ายเงินให้วัยรุ่นใช้แอปเพื่อเก็บข้อมูลพฤติกรรมการใช้งาน
- ในปี 2023 บริษัทลูกสองแห่งของ Facebook ถูกศาลรัฐบาลกลางออสเตรเลียสั่งปรับรวม 20 ล้านดอลลาร์ออสเตรเลีย จากการกระทำที่ทำให้เข้าใจผิดซึ่งอาจละเมิดกฎหมายคุ้มครองผู้บริโภคของออสเตรเลีย
- จุดเน้นของการวิเคราะห์ครั้งนี้คือ แม้แอปจะถูกถอดไปแล้ว ก็ยังสามารถยืนยันการทำงานเชิงเทคนิคในเวลานั้นได้ผ่าน archived APK
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ถ้าสรุปว่าอะไรกันแน่ที่ถูกยกเป็นปัญหา มีรายละเอียดบางอย่างที่หลายบทความดูเหมือนจะละไว้: ในมุมมองของผม ดูเหมือนว่า FB จ่ายค่าตอบแทนให้ผู้ใช้ SC เข้าร่วม การวิจัยตลาด และให้ติดตั้งพร็อกซี
บทความส่วนใหญ่เขียนให้อ่านเหมือนเป็นการแฮ็ก แต่จริง ๆ แล้วดูไม่ใช่อย่างนั้น ผมอยากรู้เพิ่มเติมว่าผู้เข้าร่วมถูกบอกว่ารับเงินเป็นค่าตอบแทนอะไร แต่ก็ไม่น่าจะเป็นไปได้ที่พวกเขาจะไม่รู้เลยว่าพฤติกรรมของตนถูกเฝ้าติดตาม
ข้อกล่าวอ้างที่ว่าหากหนึ่งในคู่สื่อสารกำลังทำลายการเข้ารหัสด้วยเครื่องมือที่บุคคลที่สามจัดหาให้ นั่นคือการดักฟัง ดูค่อนข้างอ่อน ผมไม่ใช่นักกฎหมาย แต่ถ้านี่คือการดักฟัง งั้นการที่ผมถอดรหัสและวิเคราะห์ทราฟฟิก API ของบริการใดบริการหนึ่งด้วย SSL proxy ในเครื่องตัวเองก็นับเป็นการดักฟังด้วยหรือ?
หวังว่าพวกเขาจะบอกอย่างตรงไปตรงมาว่าเก็บอะไรบ้าง ในบทความไม่ได้บอกว่า หน้าจอยินยอม ก่อนติดตั้งพร็อกซีมีลักษณะอย่างไร
กรณีนั้นทำให้แอป Onavo ถูกถอดออกจากแอปสโตร์และนำไปสู่ค่าปรับ
แยกออกไปอีก มีโปรแกรมที่ Facebook จ่ายเงินให้วัยรุ่นติดตั้ง Facebook Research VPN ผ่านช่องทางการกระจายแบบองค์กร เพื่อเลี่ยง App Store และกฎต่าง ๆ และเวอร์ชันที่จ่ายเงินนั้นล่วงล้ำกว่ามาก
ดังนั้นกรณี Onavo นี้จึงแก้ต่างไม่ได้เลย
https://apkpure.com/onavo-protect-from-facebook/com.onavo.sp...
https://techcrunch.com/2019/01/29/facebook-project-atlas/?re...
บล็อกโพสต์ก็แยกระหว่างข้อถกเถียงเดิมในปี 2023 ที่ศาลรัฐบาลกลางออสเตรเลียสั่งให้บริษัทลูกของ Facebook สองแห่งจ่ายรวม 20 ล้านดอลลาร์จากพฤติกรรมที่อาจทำให้เข้าใจผิดและเข้าข่ายละเมิดกฎหมายผู้บริโภคของออสเตรเลีย กับ ข้อกล่าวหาเรื่องการดักฟัง ในครั้งนี้
สำหรับคำถามว่า “การถอดรหัสและวิเคราะห์ทราฟฟิกของตัวเองด้วย SSL proxy ในเครื่องตัวเองก็นับเป็นการดักฟังหรือ” ถ้าเป็นการดูทราฟฟิกของตัวเองบนเครือข่ายหรืออุปกรณ์ของตัวเอง แน่นอนว่าไม่ใช่
อีเมลบางส่วนชวนประทับใจในหลายแง่ โดยเฉพาะที่เผยให้เห็นว่าคนของ FB โง่หรือหยิ่งผยองแค่ไหน การพูดถึง MITM กันอย่างเปิดเผย และเขียนทิ้งไว้ว่าพวกเขาให้ใส่ชุดเครื่องมือนี้ในผลิตภัณฑ์ของบริษัทอื่นหลายแห่งด้วยนั้นโง่มากจริง ๆ
แค่ “Zuck ผมมีไอเดียเรื่องที่คุณเสนอไว้ ไว้มาคุยกันตอนเจอ” ก็ยังน่าสงสัย แต่至少ก็ไม่ใช่หลักฐานมัดตัว ดูเหมือนคนเหล่านี้ไม่เคยดูหนัง หรืออ่านข่าวเกี่ยวกับบริษัทอื่นที่ถูกจับได้เลยสักครั้ง
ปัญหาที่แท้จริงคือ การขาดจริยธรรมอย่างสิ้นเชิง ฟังดูเหมือนที่ที่ถ้ามองจริยธรรมเป็นอุปสรรค ก็อาจถูกหัวเราะเยาะในห้องประชุมหรือถูกไล่ออก วัฒนธรรมองค์กรเอนเอียงไปไล่ล่ากำไรเหนือทุกอย่าง และในอุตสาหกรรมซอฟต์แวร์ยิ่งแย่เป็นพิเศษ เพราะมีคนมากเกินไปที่ไม่คิดถึงนัยทางจริยธรรมของการกระทำของตนเลย
นี่ยังไม่ได้พูดถึง Instagram ด้วยซ้ำ
ท้ายที่สุด ดูเหมือนเพราะจ่ายเงินเยอะเกินไปและจ้างคนในวงการมากเกินไป คำวิจารณ์จึงลดลง เราทุกคนต่างมีเพื่อนที่เคยทำงานที่ Meta หรืออย่างน้อยก็อาจเคยสมัครสักครั้ง ในทางกลับกัน แทบไม่มีคนรอบตัวที่เคยอยู่ที่ที่อย่าง Anduril
ไม่ได้จะประเมินเรื่องนี้ต่ำเกินไป แต่กรณีนี้อย่างน้อยผู้ใช้ต้องดาวน์โหลด แอป Onavo ก่อน จึงไม่ใช่เรื่องที่เกิดขึ้นได้ทั่วไปนัก
สิ่งที่ผมนึกถึงบ่อยกว่าคือ webview สองแบบบน iOS ที่ยังใช้งานได้และยังไม่ถูกเลิกใช้: WKWebView กับ SFSafariViewController ทั้งสองมีวัตถุประสงค์การใช้งานที่ตั้งใจไว้ต่างกันมาก
เมื่อกดลิงก์ในแอป Facebook ควรใช้ SFSafariViewController เพราะโค้ดของแอปมองเข้าไปข้างในไม่ได้ จึงเป็นส่วนตัว แชร์คุกกี้กับ Safari และถูกสร้างมาเพื่อ “โหลดคอนเทนต์เว็บภายนอกภายในบริบทของแอปนี้” ตามตัวอักษร
แต่ FB ยังใช้ WKWebView อยู่ หากใช้ตัวนี้ก็สามารถฉีด JS ใด ๆ ลงในหน้าเว็บที่ต้องการได้ และติดตามได้หมดทั้งการนำทาง ทรัพยากรที่โหลด ฯลฯ เมื่อดูบทความนี้กับการเปิดโปงอื่น ๆ แล้ว น่ากลัวที่จะจินตนาการว่า FB เอาความสามารถนั้นไปทำอะไรบ้าง มีความเป็นไปได้สูงว่าพวกเขากำลังติดตามแม้กระทั่งว่าผู้ใช้แตะพิกเซลไหนบนเว็บไซต์ภายนอก การคิดว่าเขาอาจติดตามชื่อผู้ใช้และรหัสผ่านทั้งหมดที่กรอกใน in-app webview ฟังดูเหมือนบ้า แต่ในทางเทคนิคทำได้ แล้วเราเชื่อได้จริง ๆ หรือว่าพวกเขาจะไม่ทำ?
https://x.com/jameshartig/status/1534886418266431488
สิ่งที่ยังไม่รู้คือ ในจำนวนการติดตั้งเหล่านั้น มีกี่เปอร์เซ็นต์ที่ทราฟฟิกของคู่แข่ง FB ถูกทำ MITM
https://www.androidrank.org/application/onavo_protect_from_f...
ไม่รู้ทำไม แต่ Facebook เป็นบริษัทเทคโนโลยีบริษัทเดียวที่ผมมองในแง่ดีไม่ได้เลย Google, Microsoft, Apple, Nvidia, AMD, Intel ฯลฯ ต่างก็มีส่วนที่ชอบและไม่ชอบ แต่ Facebook นี่คือไม่ชอบล้วน ๆ
ราว 10–11 ปีก่อนผมปิดบัญชี Facebook และตั้งฟิลเตอร์ตัด Facebook ออกจากผลการค้นหา ซึ่งได้ผล ผมแทบไม่เห็นเนื้อหาเกี่ยวกับ Facebook ในฟีด Google News ด้วย แต่ยังใช้ WhatsApp อยู่ เพราะนอกจีนแล้วมันเป็น แอปแชต ที่ใหญ่ที่สุดในเอเชีย
อีกอย่างคือความไม่รับผิดชอบต่อผลที่อัลกอริทึมขยาย hate speech บริษัทอื่น ๆ ไม่มีปัญหาระดับนี้
การตลาดก็ไม่ซื่อสัตย์ แทบทุกโฆษณาและการเปิดเผยฟีเจอร์ของ Quest ใช้ภาพคอนเซ็ปต์เพื่อทำให้คนเข้าใจผิดว่าทำอะไรได้ Mark เองก็ใช้ภาษาสองแง่สองง่ามบ่อยเวลาพูดถึงปัญหา ภาษาสองแง่สองง่ามไม่ใช่สิ่งที่มีเฉพาะ Meta แต่เมื่อเทียบกับบริษัทอื่นที่ยกมา Meta ผลัก โฆษณาหลอกลวง ไปจนสุดขอบ
ในรอบ AI ครั้งนี้ ความนิยมของ Meta กลับมาเพิ่มขึ้นเพราะโมเดลแบบเปิดเวตแต่ไม่ใช่โอเพนซอร์ส และ Mark ก็พยายามสร้างภาพลักษณ์ใหม่ด้วยการบุกประชาสัมพันธ์ช่วงหลัง
ถึงอย่างนั้น ในบรรดาบริษัทที่ยกมา ผมมองว่ามีแค่ Meta ที่ในเชิงวัฒนธรรมไม่มีแกนทางศีลธรรมในงานของตน วัฒนธรรมไหลลงมาจากข้างบน และ Zuckerberg กับ Thiel ได้ปลูกฝังวัฒนธรรม “ความสำเร็จคือทุกอย่าง” ไว้ในวิธีบริหาร Meta
บริษัทอื่น ๆ ก็เป็นทุนนิยมแน่นอน แต่ยังมีความรับผิดชอบต่อผลงานของตัวเองอยู่บ้าง
ถ้าผมเป็นฝ่ายเสริมกำลังให้อีกฝ่ายก่อน ต่อให้คัดค้านต่อสาธารณะก็ไม่มีผลอะไร
ถ้อยคำที่ว่า “ในคดีแบบกลุ่มปัจจุบันที่ฟ้อง Meta เอกสารศาลมีข้อกล่าวหาว่าบริษัทละเมิด Wiretap Act” นั้นไม่ถูกต้อง
นี่ไม่ใช่ คดีดักฟัง ข้อเรียกร้องทั้งหมดเป็นการละเมิด Sherman Act หรือก็คือเกี่ยวกับการต่อต้านการผูกขาด ทนายฝ่ายโจทก์เพียงบังเอิญพบหลักฐานระหว่างกระบวนการ discovery ว่า Facebook อาจละเมิด Wiretap Act ไม่มีข้อเรียกร้องเกี่ยวกับการดักฟัง เป็นคดีต่อต้านการผูกขาด
ผมสงสัยและสับสนว่า DMCA ไม่แข็งพอสำหรับเรื่องระดับนี้หรือเปล่า เป็นปัญหาเรื่องสถานะผู้ฟ้องหรือความเสียหายที่พิสูจน์ได้ หรือฝ่ายโจทก์ลืมไป
ญาติคนหนึ่งของผมเคยเกือบสมัครเข้าร่วมงานวิจัยตลาดที่โดยสาระแล้วคล้ายกับเรื่องนี้มาก วิธีคือให้ทราฟฟิกอินเทอร์เน็ตทั้งหมดของมือถือถูกอ้อมผ่าน VPN และพร็อกซี ที่บริษัทวิจัยตลาดควบคุม และติดตั้งใบรับรองด้วย
เขาน่าจะได้รับค่าตอบแทนเล็กน้อย และก็คงยินยอมให้ติดตั้ง ผมจำไม่ได้ว่าบริษัทนั้นหลอกอะไรอย่างชัดเจน
เพียงแต่แม้โดยทั่วไปผมจะไม่ค่อยชอบนโยบายที่ปกป้องแบบพ่อแม่มากเกินไป แต่ก็สงสัยว่าการที่คนซึ่งมีความรู้ทางเทคนิคน้อยกว่ายินยอมกับเรื่องแบบนี้มีความหมายแค่ไหน แม้ไม่ได้หลอก แต่ก็ไม่ได้อธิบายให้คนที่ไม่รู้ว่าเกิดอะไรขึ้นเข้าใจได้อย่างจับใจ
อ่านบทความนี้แล้วรู้สึกว่า Facebook ตอนนี้คงมีแผนกที่เหมือน องค์กรบังหน้าของ NSA อยู่เลย
https://qz.com/1145669/googles-true-origin-partly-lies-in-ci...
ตอนนี้รถยนต์มีบริการของ Google และ Android ฝังอยู่ในระบบอินโฟเทนเมนต์ และไม่มีทางเอาออกได้ จะมีอะไรผิดพลาดได้บ้างกันนะ เมื่อบริษัทโฆษณามองเห็นหมดว่าคุณไปที่ไหนและใครอยู่ในรถกับคุณ?
โอ้โห SSLbump
น่าจะมีบรรทัดฐานคดีที่มองว่าการดักดูทราฟฟิกเครือข่ายฝั่งลูกค้าเป็นอาชญากรรมอยู่
น่าจะเป็นหนึ่งในหลายคดีที่เกี่ยวกับการดักฟังข้อมูลธนาคาร
นี่แหละเหตุผลที่เซิร์ฟเวอร์และไคลเอนต์ควรใช้ mutual TLS แลกเปลี่ยนใบรับรองกันทั้งสองฝ่าย ก่อนจะส่งข้อมูลที่เป็นอันตรายผ่านอินเทอร์เน็ต แต่ความเป็นจริงคือ ไม่เลยยยยยย
น่าเสียดายแต่ก็ไม่น่าแปลกใจ ผู้ไม่หวังดีอย่าง Meta น่าจะใส่ dark patterns ไว้หลายแบบอยู่แล้ว
ตัวอย่างเช่น ลองนึกถึงความเสี่ยงด้านความปลอดภัยจากการรั่วไหลของข้อมูลเซนเซอร์ เช่น การมอนิเตอร์ข้อมูลจาก accelerometer และ gyroscope เพื่ออนุมานข้อมูลเสียง หากแอบส่งต่อข้อมูลที่เก็บมาออกไปภายนอกและประมวลผล ก็อาจสร้างข้อมูลอ่อนไหวขึ้นมาใหม่ได้โดยไม่ต้องเข้าถึงไมโครโฟนของอุปกรณ์โดยตรง
ถ้าพวกเขาทำเรื่องแบบนี้ได้จริงก็ไม่แปลก
Meta รวมถึงบริษัทและหน่วยงานรัฐที่เป็นอันตรายอื่น ๆ มีแนวโน้มว่าจะใช้ เทคนิคดักฟัง ในสภาพแวดล้อมจริงที่มากกว่า แย่กว่า และเรียบง่ายกว่านี้อีกมาก