ป้ายความเป็นส่วนตัวคือข้อมูลเปิดเผยที่ควรตรวจสอบ ไม่ใช่ผลการวัดทุกสิ่งที่แอปรู้
เราไม่อาจประกาศผู้ชนะสากลที่มีเหตุผลรองรับว่าเป็น “แอปส่งข้อความที่เก็บข้อมูลน้อยที่สุด” โดยยังไม่กำหนดว่าจะนับอะไร: ตัวระบุที่ใช้ลงทะเบียน ข้อมูลสมุดรายชื่อ บันทึกการเชื่อมต่อที่เก็บไว้ การใช้เพื่อโฆษณา หรือเนื้อหาข้อความ? ป้ายความเป็นส่วนตัวเป็นจุดเริ่มต้นที่มีประโยชน์ ไม่ใช่ผลการวัดทุกสิ่งที่แอปประมวลผล
คู่มือนี้อธิบายวิธีเปรียบเทียบข้อมูลที่เปิดเผย ไม่ใช่การตรวจสอบอิสระที่เสร็จสมบูรณ์ของแอปส่งข้อความทุกตัว และไม่ได้มอบตราเก็บข้อมูลน้อยที่สุดให้ Livara หรือคู่แข่งรายใด
อ่านป้ายก่อนนับหมวดหมู่
ส่วน App Privacy ของ Apple และส่วน Data safety ของ Google Play อาศัยคำประกาศจากนักพัฒนา แต่มีนิยามต่างกัน คำแนะนำของ Apple แยกข้อมูลที่เชื่อมโยงกับผู้ใช้ การติดตาม และวัตถุประสงค์ในการเก็บข้อมูล การประมวลผลที่อยู่เฉพาะบนอุปกรณ์ไม่ถือเป็นการเก็บข้อมูล และการประมวลผลชั่วคราวกับการเปิดเผยข้อมูลที่เป็นทางเลือกบางอย่างมีข้อยกเว้นเฉพาะ
คำแนะนำของ Google ก็มีข้อยกเว้นเช่นกัน: ข้อมูลที่เข้ารหัสแบบต้นทางถึงปลายทางซึ่งเข้าเงื่อนไขและตัวกลางอ่านไม่ได้ อยู่นอกขอบเขตการเปิดเผยข้อมูลที่เก็บรวบรวม และการส่งต่อไปยังผู้ให้บริการบางกรณีไม่นับเป็นการแชร์ คำว่า “เข้ารหัสระหว่างส่ง” ในหน้าร้านไม่ใช่คำรับรองการเข้ารหัสแบบต้นทางถึงปลายทาง ดังนั้นหมวดหมู่ที่ว่างจึงไม่ได้พิสูจน์ว่าไม่มีคำขอผ่านเครือข่ายหรือความสัมพันธ์กับผู้ให้บริการ
อย่าเทียบจำนวนช่องของ Apple กับจำนวนช่องของ Google แล้วประกาศผู้ชนะ ควรเทียบภายในร้านเดียวกัน วันที่เดียวกัน ภูมิภาคเดียวกัน และสมมติฐานเกี่ยวกับฟีเจอร์เดียวกัน
เปรียบเทียบความเป็นส่วนตัวผ่านห้าชั้น
| หลักฐาน | คำถามที่มีประโยชน์ | สิ่งที่พิสูจน์เพียงลำพังไม่ได้ |
|---|---|---|
| ป้ายในร้านแอป | ประกาศประเภทข้อมูลและการใช้งานใดบ้าง? | ความถูกต้องทั้งหมดหรือการเก็บรักษาจริง |
| นโยบายความเป็นส่วนตัว | ใครได้รับข้อมูล เพื่ออะไร และนานเท่าใด? | การทำงานจริงตรงตามนโยบายหรือไม่ |
| สิทธิ์ของอุปกรณ์ | แอปเข้าถึงรายชื่อ ตำแหน่ง ไมโครโฟน หรือรูปภาพได้หรือไม่? | เกิดอะไรขึ้นกับข้อมูลที่อัปโหลดไปแล้ว |
| เอกสารโปรโตคอล | ส่วนใดและกุญแจใดปกป้องเนื้อหา? | การปกป้องทุกอุปกรณ์หรือทุกบิลด์ซอฟต์แวร์ |
| การประเมินอิสระ | ทดสอบเวอร์ชันและองค์ประกอบใด และแก้ไขอะไรแล้ว? | ความปลอดภัยถาวรของรุ่นในอนาคต |
แต่ละชั้นตอบคนละคำถาม ไคลเอนต์โอเพนซอร์สสามารถตรวจดูได้ แต่ข้อเท็จจริงนี้ไม่ได้เปิดเผยการเก็บรักษาบนเซิร์ฟเวอร์ที่ใช้งานจริงโดยตัวมันเอง การตรวจสอบอาจครอบคลุมการเข้ารหัสโดยไม่ได้ตรวจระบบวิเคราะห์ข้อมูล อ่านขอบเขตก่อนนำสิ่งใดมาใช้เป็นคะแนนความเป็นส่วนตัว
ใช้แบบบันทึกการเปรียบเทียบนี้
สำหรับแต่ละแอปที่กำลังพิจารณา ให้บันทึกข้อมูลต่อไปนี้เป็นการส่วนตัว บันทึกสั้น ๆ ที่มีวันที่มีประโยชน์กว่าการจัดอันดับที่ไม่มีหลักฐาน
| หัวข้อ | สิ่งที่ควรจด |
|---|---|
| ผลิตภัณฑ์และแพลตฟอร์ม | แอปที่แน่นอน ลิงก์ร้าน ระบบปฏิบัติการ และเวอร์ชัน |
| วันที่สังเกต | ตรวจป้ายและนโยบายเมื่อใด |
| การลงทะเบียน | ตัวระบุโทรศัพท์ อีเมล หรือการชำระเงินที่จำเป็นและเป็นทางเลือก |
| การค้นหาผู้ติดต่อ | สมุดรายชื่อ ชื่อผู้ใช้ คิวอาร์โค้ด ลิงก์เชิญ หรือรหัสบัญชี |
| บันทึกทางเทคนิค | ข้อมูล IP อุปกรณ์ การวินิจฉัย และการใช้งานที่ประกาศไว้ |
| การเก็บรักษา | ระยะเวลาที่ระบุ เงื่อนไขการลบ หรือ “ไม่ได้ระบุ” |
| ข้อยกเว้นของฟีเจอร์ | ข้อมูลสำรอง บอต การติดต่อธุรกิจ การชำระเงิน ช่องสาธารณะ และการโทร |
| ช่องว่างของหลักฐาน | สิ่งที่เอกสารไม่ได้ตอบ |
หากนโยบายบอกเพียงว่าเก็บข้อมูล “เท่าที่จำเป็น” ให้ระบุว่าไม่ทราบระยะเวลาที่แน่นอน แทนการแต่งขึ้น หากป้ายเปลี่ยนหลังอัปเดต ให้เก็บวันที่ก่อนหน้าไว้กับบันทึกเพื่อให้ยังตีความการเปรียบเทียบได้
ไม่ต้องใช้เบอร์โทรเป็นเพียงมิติหนึ่ง ไม่ใช่ผลทั้งหมด
Session และ SimpleX มีวิธีเชื่อมต่อโดยไม่อาศัยตัวตนที่ยึดกับเบอร์โทรศัพท์ Threema กำหนดให้การเชื่อมโยงโทรศัพท์หรืออีเมลเป็นทางเลือก เอกสารสาธารณะของ Livara อธิบายการลงทะเบียนโดยไม่ใช้เบอร์โทรหรืออีเมล แต่ก็อธิบายเมทาดาทาการกำหนดเส้นทางและสมาชิกภาพด้วย ไม่ควรมองว่าสถาปัตยกรรมเหล่านี้เหมือนกันจนใช้แทนกันได้
ขณะนี้ Signal มีเอกสารอธิบาย ทางเลือกการลงทะเบียนไม่ใช้เบอร์โทรใน Android รุ่นเบตา นั่นไม่ได้หมายความว่า Signal ทุกเวอร์ชันหรือทุกบัญชีเดิมไม่ใช้เบอร์โทร ชื่อผู้ใช้บนบัญชีที่ผูกกับเบอร์และการสร้างบัญชีโดยไม่ใช้เบอร์เป็นคนละฟีเจอร์
แม้ไม่มีเบอร์ รูปโปรไฟล์ที่ใช้ซ้ำ บัญชีชำระเงิน ไฟล์ที่แชร์ ที่อยู่ IP หรือบริบทของบทสนทนาก็อาจเชื่อมบัญชีกับบุคคลได้ “ไม่ต้องใช้โทรศัพท์” ไม่ใช่หลักฐานว่าปกปิดตัวตนได้ทั้งหมด สำหรับประเด็นข้อมูลการกำหนดเส้นทางที่แยกต่างหาก โปรดดูคำอธิบายเมทาดาทาของการส่งข้อความ
ทดสอบการเข้าถึงรายชื่อโดยไม่เปิดเผยสมุดรายชื่ออย่างไร
- ติดตั้งแอปทางการและปฏิเสธสิทธิ์รายชื่อในตอนแรก
- เพิ่มผู้ติดต่อทดสอบหนึ่งคนที่ยินยอม โดยใช้ตัวระบุ คำเชิญ หรือคิวอาร์โค้ดที่รองรับ
- ตรวจว่าการส่งข้อความตามปกติทำงานโดยไม่เข้าถึงสมุดรายชื่อได้หรือไม่
- ตรวจการตั้งค่าซิงค์รายชื่อในแอปควบคู่กับสิทธิ์ของระบบปฏิบัติการ สองอย่างนี้ไม่ใช่ตัวควบคุมเดียวกันเสมอไป
- หากเคยซิงค์รายชื่อแล้ว ให้หาตัวเลือกลบแยกต่างหากหรือขั้นตอนยื่นคำขอที่มีเอกสารระบุ การถอนสิทธิ์จำกัดการเข้าถึงอุปกรณ์ในอนาคต แต่ไม่จำเป็นต้องลบสำเนาบนเซิร์ฟเวอร์
อย่าอัปโหลดสมุดรายชื่อเพียงเพื่อดูว่าแอปอัปโหลดมันหรือไม่ หน้าขอสิทธิ์แสดงการเข้าถึงที่ร้องขอ ไม่ใช่การตรวจสอบการไหลของข้อมูลอย่างครบถ้วน การตรวจเครือข่ายอาจเผยปลายทางและเวลา แต่การเข้ารหัสอาจทำให้ไม่เข้าใจฟิลด์ข้อมูลที่ส่ง
สิ่งที่ E2EE ไม่ครอบคลุมในการเปรียบเทียบ
การเข้ารหัสแบบต้นทางถึงปลายทางปกป้องเนื้อหาที่อยู่ในขอบเขตระหว่างจุดปลายทางที่เข้าร่วม ไม่ได้ลบตัวระบุบัญชี เวลาเชื่อมต่อ บันทึกสมาชิกกลุ่ม หรือข้อมูลโทเคนพุชโดยอัตโนมัติ และไม่ได้ปกป้องสำเนาที่จงใจส่งให้บอต เครื่องมือธุรกิจ หรือบริการช่วยเหลือนอกบทสนทนาที่เข้ารหัสนั้น
สำหรับ Livara โดยเฉพาะ เอกสารความปลอดภัย แยกข้อความตรงที่เข้ารหัสและกลุ่มส่วนตัวที่เข้ากันได้ออกจากช่องสาธารณะที่เซิร์ฟเวอร์อ่านได้ การตกลงกุญแจแบบไฮบริดเป็นข้ออ้างเรื่องการปกป้องเนื้อหา ไม่ใช่หลักฐานว่าเก็บเมทาดาทาน้อยกว่าแอปส่งข้อความทุกตัว บทความนี้ไม่ได้วัดพฤติกรรมเซิร์ฟเวอร์ของบริการนั้นอย่างอิสระ
เลือกข้อมูลขั้นต่ำที่จำเป็นสำหรับการใช้งานของคุณ
เริ่มจากข้อมูลที่ต้องการปกปิดมากที่สุด หากเป็นเบอร์โทร ให้ทดสอบการลงทะเบียนแบบไม่ใช้เบอร์ หากเป็นสมุดรายชื่อ ให้ตรวจการค้นหาผู้ติดต่อด้วยตนเอง หากเป็นประวัติแชตที่อ่านได้ในคลาวด์ ให้ตรวจข้อมูลสำรองแยกต่างหาก หากเป็นเมทาดาทาการเชื่อมต่อ ให้อ่านการออกแบบการกำหนดเส้นทางและการเก็บรักษาแทนรายการอัลกอริทึมเข้ารหัส
คำถามสุดท้ายที่มีประโยชน์คือ: บริการนี้รู้อะไรเมื่อฉันใช้ฟีเจอร์ที่จำเป็นจริง ๆ และฉันหลีกเลี่ยงการเปิดเผยข้อใดได้บ้าง? คำถามนี้นำไปสู่การตัดสินใจที่ตรงไปตรงมากว่าถ้วยรางวัล “ข้อมูลน้อยที่สุด” เพียงใบเดียว
