"ยุติยุคของ 'สแปมคำเชิญ'? อะไรที่ทำให้ Find Friends ของ Bluesky แตกต่าง"

"ค้นหาเพื่อน"——ฟีเจอร์ที่เป็นเรื่องปกติในโซเชียลเน็ตเวิร์กมานาน แต่จริงๆ แล้วกลับเป็น "ปัญหา" มานานหลายปี โซเชียลเน็ตเวิร์กจะอ่านข้อมูลจากสมุดโทรศัพท์ในสมาร์ทโฟนเพื่อค้นหาว่าใครอยู่ในโซเชียลเน็ตเวิร์กเดียวกัน และยังส่งข้อความเชิญชวนไปยังผู้ที่ยังไม่ได้ลงทะเบียนอีกด้วย สำหรับผู้ใช้มันเป็นทางลัดในการพบเจอกันใหม่ แต่สำหรับผู้รับมันมักจะกลายเป็น "SMS เชิญชวนแอป" ที่มาถึงอย่างไม่คาดคิด และเนื่องจากเกี่ยวข้องกับข้อมูลส่วนบุคคลที่สำคัญอย่างหมายเลขโทรศัพท์ ความเสี่ยงของการรั่วไหลและการใช้งานในทางที่ผิดจึงอยู่ใกล้เคียงเสมอ ในเดือนธันวาคม Bluesky ได้เปิดตัว "Find Friends" โดยเน้นที่ "ความเป็นส่วนตัว" ซึ่งแสดงถึงความตั้งใจที่ชัดเจนที่จะไม่ปฏิบัติตามรูปแบบความสำเร็จเก่าๆ นี้ TechCrunch

คำประกาศว่าจะไม่ส่ง "สแปมเชิญชวน"

ประเด็นที่ TechCrunch รายงานในครั้งนี้ชัดเจนว่า Bluesky จะไม่ส่ง SMS เชิญชวนอัตโนมัติแม้ว่าจะอัปโหลดรายชื่อผู้ติดต่อก็ตามแอปจะไม่ส่ง SMS เชิญชวนอัตโนมัติ หากจะทำก็จะจำกัดให้เป็นการกระทำด้วยตนเองที่ "ผู้ใช้ส่งข้อความถึงเพื่อนด้วยความตั้งใจของตนเอง" เมื่อพิจารณาว่าโซเชียลเน็ตเวิร์กหลายแห่งใช้การจับคู่รายชื่อผู้ติดต่อเป็นเครื่องมือในการเติบโต (เส้นทางไวรัล) และบังคับให้ส่งคำเชิญอย่างครึ่งบังคับ การประกาศจุดยืนนี้ถือเป็นการท้าทายอย่างมาก TechCrunch

อย่างไรก็ตาม มีการแลกเปลี่ยนเกิดขึ้นที่นี่ เนื่องจาก Bluesky ออกแบบมาเพื่อ "ไม่บันทึกหรือติดตามหมายเลขโทรศัพท์แต่ละหมายเลข" จึงไม่สามารถตรวจสอบล่วงหน้าได้ว่าผู้ติดต่ออยู่ใน Bluesky แล้วหรือไม่ ผลที่ตามมาคือ แม้ว่าเพื่อนจะส่งข้อความเชิญชวนด้วยความตั้งใจดี แต่ผู้รับก็อาจได้รับข้อความแม้ว่าจะ "เข้าร่วมแล้ว" ก็ตาม 9to5Mac เรียกสิ่งนี้ว่า "ข้อบกพร่อง" แต่ถือว่าเป็นราคาที่เล็กน้อยสำหรับการปกป้องความเป็นส่วนตัว 9to5Mac

กลไก: การยินยอมสองชั้น (Double Opt-In) + การยืนยันหมายเลข

Find Friends ของ Bluesky จะไม่จับคู่เว้นแต่จะมีเงื่อนไขต่อไปนี้ครบถ้วน

• ทั้งสองฝ่ายเปิดใช้งาน Find Friends

• ทั้งสองฝ่ายบันทึกกันและกันในรายชื่อผู้ติดต่อ (การบันทึกฝ่ายเดียวจะไม่สำเร็จ)

• ยืนยันหมายเลขของตนเองผ่าน SMS ก่อนอัปโหลดรายชื่อผู้ติดต่อ

TechCrunch อธิบายว่าในขณะที่ใช้งานจะมีการป้อนรหัส 6 หลักที่ส่งมาทาง SMS เพื่อยืนยันหมายเลข โดยมีเป้าหมายเพื่อป้องกันการใช้งานในทางที่ผิดเช่น "ฟิชชิ่ง" ที่ใส่หมายเลขสุ่มจำนวนมากเพื่อ "ตกเบ็ด" ว่าหมายเลขนี้อยู่ใน Bluesky หรือไม่ นอกจากนี้ หากไม่ใช้ก็จะไม่กลายเป็น "ฝ่ายที่ถูกค้นพบด้วยหมายเลขโทรศัพท์" —— ผู้ที่ไม่ต้องการให้เพื่อนร่วมงานพบสามารถเลือกที่จะไม่ใช้ฟังก์ชันนี้ TechCrunch

การให้บริการยังเป็นไปอย่างค่อยเป็นค่อยไป โดยในระยะแรกจะจำกัดเฉพาะบางประเทศในแอปพลิเคชันมือถือ (รวมถึงญี่ปุ่น) TechCrunch

"คู่แฮช" + "คีย์ฮาร์ดแวร์ที่แยกต่างหาก" — การป้องกันที่ตั้งอยู่บนสมมติฐานของการรั่วไหล

สิ่งที่น่าสนใจที่สุดในครั้งนี้คือ Bluesky ได้จัดการกับ "การจับคู่รายชื่อผู้ติดต่อ" เป็นปัญหาด้านการออกแบบความปลอดภัยอย่างตรงไปตรงมา ตามที่ TechCrunch และบล็อกอย่างเป็นทางการของ Bluesky กล่าว หมายเลขโทรศัพท์ที่อัปโหลดจะถูกเก็บเป็น "คู่แฮช (hashed pairs)" ของ "หมายเลขของตนเอง × หมายเลขของผู้อื่น" แทนที่จะเป็นการแฮชแบบธรรมดา ซึ่งจะทำให้การคำนวณย้อนกลับ (reverse engineering) ทำได้ยากขึ้นแม้ว่าข้อมูลจะรั่วไหลก็ตาม นอกจากนี้การเข้ารหัสยังเชื่อมโยงกับคีย์ความปลอดภัยฮาร์ดแวร์ที่เก็บแยกต่างหากจากฐานข้อมูล ผู้ใช้ยังสามารถลบข้อมูลหรือยกเลิกการเข้าร่วมได้ในภายหลัง TechCrunch

TechCrunch ยังรายงานด้วยว่ารายละเอียดทางเทคนิคนี้ได้ถูกแชร์ล่วงหน้าในรูปแบบ RFC กับชุมชนด้านความปลอดภัยเพื่อรับฟังความคิดเห็น ซึ่งหมายความว่า Bluesky เองก็ยอมรับว่า "การจับคู่รายชื่อผู้ติดต่อมีการใช้งานที่เสี่ยง" และได้เปิดเผยการออกแบบเพื่อการอภิปรายก่อนที่จะนำไปใช้จริง TechCrunch

ทำไมถึงต้องทำขนาดนี้: "Cold Start" และ "เพื่อนในชีวิตจริง"

Bluesky ได้ตั้งข้อสังเกตในบล็อกว่า โซเชียลเน็ตเวิร์กเดิมทีเป็น "ที่ที่เชื่อมต่อกับคนที่รู้จักจริงๆ" แต่เสียงรบกวนจากอัลกอริทึมและการแข่งขันด้านการมีส่วนร่วมทำให้สิ่งนี้หายไป หากต้องการกลับมาเป็น "โซเชียลเน็ตเวิร์กที่พบเจอคนรู้จัก" อีกครั้ง การค้นหาเพื่อนเป็นสิ่งที่หลีกเลี่ยงไม่ได้ นอกจากนี้ในบริบทของ RFC ยังมีการกล่าวถึง "ปัญหา Cold Start ในการสร้างความหนาแน่นของกราฟสังคม" และขนาดของผู้ใช้ Bluesky

กล่าวโดยสรุป Find Friends ไม่ใช่แค่การเพิ่มฟีเจอร์ที่สะดวกสบาย แต่เป็นหัวข้อที่ใกล้เคียงกับแก่นของบริการว่า "โซเชียลเน็ตเวิร์กที่มุ่งเน้นการกระจายตัวจะสร้างความสัมพันธ์เริ่มต้นอย่างไร"

ปฏิกิริยาบน SNS (ชุมชน): การต้อนรับและความสงสัยอยู่ร่วมกัน

การออกแบบในครั้งนี้ได้ก่อให้เกิดการอภิปราย ที่นี่จะจัดเรียงแนวโน้มโดยเน้นที่เสียงจาก Hacker News และ GitHub Discussions เป็นหลัก

1) "แนวคิดคล้าย Private Set Intersection" — แนะนำการแก้ปัญหาที่เน้นการเข้ารหัสมากขึ้น

ใน Hacker News มีการยกPrivate Set Intersection (แนวคิดในการหาส่วนที่เหมือนกันของเซ็ตโดยไม่เปิดเผยข้อมูล) เป็นเทคโนโลยีที่เกี่ยวข้อง และมีการพูดคุยเกี่ยวกับทิศทางที่ว่า "การไม่แชร์หมายเลขโทรศัพท์ในรูปแบบข้อความธรรมดาจะช่วยหลีกเลี่ยงการโจมตีได้ทั้งหมด" แต่ก็มีความคิดเห็นที่ว่า "อาจจะเกินความจำเป็นในด้านการขยายตัว" Hacker News

2) "มีการพูดถึงความปลอดภัย แต่สุดท้ายก็ต้องเชื่อถือเซิร์ฟเวอร์ใช่ไหม?"

ใน Hacker News เช่นเดียวกัน มีมุมมองที่สงสัยว่า RFC พูดถึง "ความปลอดภัย" แต่ "สุดท้ายแล้วก็ต้องเชื่อถือเซิร์ฟเวอร์/อินสแตนซ์" เป็นความคิดเห็นที่มีความรู้สึกจากการทำงานจริงว่า การยืนยันหมายเลข (การป้องกันการสวมรอย) และการออกแบบที่ไม่ส่งหมายเลขไปยังเซิร์ฟเวอร์นั้นยากที่จะอยู่ร่วมกันได้ Hacker News

3) "หมายเลขโทรศัพท์ยังคงเสี่ยงแม้จะถูกแฮช" — ปัญหาความเล็กของพื้นที่หมายเลข

ความคิดเห็นอื่นๆ ระบุว่า "หมายเลขโทรศัพท์ไม่เพียงพอที่จะเป็นเอกลักษณ์ และแฮชอาจถูกจัดการด้วยตารางค้นหา" ซึ่งเป็นปัญหาที่เรียกว่า "พื้นที่หมายเลขแคบ" Bluesky พยายามเพิ่มความยากในการคำนวณย้อนกลับด้วยการใช้ "คู่แฮช" แต่ความกังวลของผู้ใช้ยังคงมีอยู่ Hacker News

4) ใน GitHub มีการเรียกร้องให้ "ระบุรายละเอียดให้ชัดเจน" และ "รายชื่อผู้ติดต่อไม่เท่ากับโซเชียล"

ใน GitHub Discussions มีการให้ข้อเสนอแนะที่ลงลึกในรายละเอียดของการออกแบบ เช่น การอธิบายเกี่ยวกับ **การรีไซเคิลหมายเลขโทรศัพท์ (การจัดสรรหมายเลขใหม่)** ที่ไม่ชัดเจน ควรแสดงโค้ดจำลองให้เร็วขึ้น GitHub

ความคิดเห็นอื่นๆ ระบุว่า "สมุดโทรศัพท์ของตนเองไม่ตรงกับกราฟโซเชียล ดังนั้นจะไม่ใช้ฟังก์ชันนี้" แต่ตราบใดที่ยังคงเป็นการยินยอมและไม่เก็บ "ข้อมูลเพิ่มเติมสำหรับการรวมชื่อ" ที่ไม่จำเป็น ก็จะไม่กังวล GitHub

สรุป: Find Friends เป็น "คำสัญญา" มากกว่า "ฟีเจอร์"

Find Friends ของ Bluesky ดูเผินๆ เหมือนเป็นการอัปเดตว่า "ในที่สุดก็มีการค้นหาเพื่อน" แต่เนื้อหาภายในคือการแสดง "คำสัญญา" ต่อความสมดุลระหว่างความเป็นส่วนตัวและการเติบโต โดย (1) ตัดสิ่งล่อใจในการเชิญอัตโนมัติ, (2) ให้สิทธิ์เลือกแก่ "ฝ่ายที่ถูกค้นพบ" ด้วยการยินยอมสองชั้น, (3) ออกแบบโดยสมมติฐานว่าข้อมูลอาจรั่วไหล, และ (4) เผยแพร่ RFC ล่วงหน้าเพื่อรับการตรวจสอบจากภายนอก TechCrunch

แน่นอนว่า เนื่องจากหมายเลขโทรศัพท์