เพื่อความเป็นส่วนตัวของเสียง ให้ตรวจสอบทั้งเส้นทางของเสียงและสิ่งที่เกิดขึ้นกับข้อความที่สร้างจากเสียงนั้น
การถอดเสียงข้อความเสียงและการแปลอาจทำบนอุปกรณ์ หรืออาจพึ่งพาบริการอื่น ดังนั้น การมีคุณสมบัติเหล่านี้เพียงอย่างเดียวไม่ได้หมายความว่าการเข้ารหัสจากต้นทางถึงปลายทางถูกทำลาย คำถามสำคัญคือ เพื่อทำงานนี้ ใครหรือระบบใดจะเข้าถึงเนื้อหาในรูปแบบที่เข้าใจได้?
ไฟล์เสียงต้นฉบับ ข้อความที่ถอดเสียง คำแปล และแบ็กอัปเป็นสิ่งที่แยกจากกันสี่อย่าง การปกป้องอย่างหนึ่งไม่ได้พิสูจน์ว่าอย่างอื่นได้รับการปกป้องด้วย
แยกเส้นทางการประมวลผลทั้งสามแบบ
| เส้นทาง | ขอบเขตความไว้วางใจ | คำถามสำคัญ |
|---|---|---|
| ประมวลผลในอุปกรณ์ทั้งหมด | อุปกรณ์และซอฟต์แวร์ที่ทำงานนั้น | เสียงหรือข้อความออกจากอุปกรณ์หรือไม่? |
| ประมวลผลบนคลาวด์ทั่วไป | บริการประมวลผลและโครงสร้างพื้นฐานของบริการนั้น | รับเนื้อหาใดไปและเก็บไว้นานเท่าใด? |
| ประมวลผลบนคลาวด์ที่มีการปกป้องเป็นพิเศษ | การออกแบบตามที่กล่าวอ้าง ฮาร์ดแวร์ และกลไกตรวจสอบ | มีการเผยแพร่หลักประกันทางเทคนิค การประเมิน และข้อจำกัดอะไรบ้าง? |
คำว่า «บนเซิร์ฟเวอร์» เพียงอย่างเดียวไม่ได้บอกรายละเอียดว่าผู้ดำเนินการเข้าถึงอะไรได้บ้าง การออกแบบบางแบบใช้สภาพแวดล้อมที่ได้รับการปกป้อง ในทางกลับกัน ชื่ออย่าง «AI ส่วนตัว» ก็ไม่ใช่หลักฐานที่เพียงพอในตัวเองเช่นกัน ต้องระบุสถาปัตยกรรมจริงและเงื่อนไขการใช้งานให้ชัดเจน
ถอดเสียงบนอุปกรณ์ได้จริงหรือไม่?
ได้ WhatsApp ระบุในประกาศอย่างเป็นทางการเรื่องการถอดเสียงข้อความเสียงว่าข้อความถูกสร้างบนอุปกรณ์ ตัวอย่างนี้แสดงให้เห็นว่าไม่ควรมองว่าคุณสมบัติถอดเสียงทุกแบบเป็นการประมวลผลบนคลาวด์ โปรดตรวจสอบความพร้อมใช้งาน ภาษา และการตั้งค่าในเวอร์ชันที่คุณใช้
ในด้านการแปล เอกสาร Google ML Kit ก็อธิบายการประมวลผลข้อความบนอุปกรณ์เช่นกัน อาจต้องดาวน์โหลดโมเดลภาษาก่อน การต้องใช้อินเทอร์เน็ตเพื่อรับโมเดลเพียงอย่างเดียวไม่ได้หมายความว่าข้อความจะถูกส่งไปเพื่อแปล คุณภาพการแปลก็ต้องประเมินตามภาษาและการใช้งานของคุณด้วย
สิ่งเหล่านี้เป็นตัวอย่างของสถาปัตยกรรม ไม่ใช่การรับรองว่าแอปทุกตัวที่ใช้คำว่า «บนอุปกรณ์» จะทำงานเหมือนกัน
ข้อความที่สร้างขึ้นจะอยู่ที่ไหน?
แม้จะประมวลผลบนอุปกรณ์ ผลลัพธ์ก็อาจเข้าไปอยู่ในประวัติ การค้นหาบนอุปกรณ์ การแจ้งเตือน คลิปบอร์ด หรือแบ็กอัป เมื่อตรวจสอบคุณสมบัติ อย่าถามเพียงว่า «เสียงถูกประมวลผลที่ไหน?» แต่ให้ถามด้วยว่า «ข้อความที่สร้างขึ้นใหม่ถูกเก็บไว้ที่ไหน และใครเห็นได้บ้าง?»
หากส่งข้อความนั้นต่อไปยังผู้ติดต่อ ก็ต้องตรวจสอบเส้นทางการส่งนั้นแยกต่างหาก การเข้ารหัสผลลัพธ์หลังประมวลผลไม่อาจย้อนลบการเข้าถึงข้อมูลนำเข้าที่บริการหนึ่งได้รับไปแล้ว นอกจากนี้ การลบเสียงต้นฉบับก็ไม่ได้รับประกันว่าสำเนาข้อความทุกชุดจะถูกลบด้วย
ภาพนี้เป็นแนวคิดประกอบ ไม่ใช่แผนผังทางเทคนิคที่ผ่านการตรวจสอบของเส้นทางประมวลผลเสียงใน Livara
ถามหกข้อนี้ก่อนเปิดใช้คุณสมบัติ
- ประมวลผลที่ไหน? บนอุปกรณ์ เซิร์ฟเวอร์ของบริการรับส่งข้อความ หรือผู้ให้บริการรายอื่น?
- ส่งข้อมูลอะไรไป? เสียงทั้งหมด ส่วนที่เลือก ข้อความ หรือเพียงคำขอดาวน์โหลดโมเดล?
- ใครเข้าถึงได้บ้าง? ผู้ดำเนินการ ผู้รับจ้าง ผู้ตรวจสอบที่เป็นมนุษย์ หรือเฉพาะสภาพแวดล้อมทางเทคนิคที่กำหนดไว้?
- นโยบายการเก็บรักษาเป็นอย่างไร? มีการใช้ข้อมูลนำเข้าหรือผลลัพธ์เพื่อรายงานข้อผิดพลาด ปรับปรุงโมเดล หรือฝึกโมเดลหรือไม่ และผู้ใช้มีทางเลือกอะไรบ้าง?
- ลบและกู้คืนผลลัพธ์อย่างไร? ตรวจสอบประวัติ แบ็กอัป อุปกรณ์ที่เชื่อมต่อ และไฟล์ที่ส่งออกแยกกัน
- มีหลักฐานอะไรบ้าง? เอกสารที่ระบุเวอร์ชัน การประเมินอิสระ และการทดสอบที่ทำซ้ำได้ มีประโยชน์กว่าคะแนนเพื่อการโฆษณา
สำหรับเนื้อหาเกี่ยวกับงานหรือเสียงของผู้อื่น ให้ตรวจสอบความยินยอมและกฎขององค์กรด้วย การได้รับอนุญาตให้ฟังข้อความเสียงไม่ได้หมายความว่าจะได้รับอนุญาตให้ส่งเสียงนั้นไปยังผู้ประมวลผลรายอื่นทุกรายด้วยเสมอไป
ทดสอบอย่างไรโดยไม่เปิดเผยข้อมูล?
ใช้ไฟล์เสียงที่ไม่มีข้อมูลอ่อนไหวซึ่งคุณบันทึกเองเพื่อทดสอบ หลังจากโมเดลบนอุปกรณ์พร้อมแล้ว การใช้คุณสมบัติได้ขณะออฟไลน์อาจเป็นสัญญาณของการประมวลผลบนอุปกรณ์ แต่เพียงเท่านี้ไม่ได้พิสูจน์ว่าแอปจะไม่ส่งข้อมูลในภายหลัง การใช้ไม่ได้ขณะออฟไลน์ก็ไม่ใช่หลักฐานในตัวเองว่ามีการส่งเนื้อหาที่ไม่ได้เข้ารหัสเช่นกัน
เทียบผลกับเอกสารของผลิตภัณฑ์ หากคำตอบยังไม่ชัดเจน ให้ปิดตัวเลือกการประมวลผลสำหรับเสียงที่มีข้อมูลอ่อนไหว หรือใช้เฉพาะส่วนที่จำเป็นและไม่มีข้อมูลอ่อนไหว สำหรับการตัดสินใจในภาพรวม โปรดดูเช็กลิสต์การเลือกแอปรับส่งข้อความที่ปลอดภัย
เราบอกอะไรเกี่ยวกับ Livara ได้บ้าง?
หน้าความปลอดภัยของ Livara อธิบายการปกป้องข้อความเสียงในแชตส่วนตัว แต่จากคำอธิบายนี้ไม่สามารถสรุปได้ว่ามีหรือไม่มีคุณสมบัติถอดเสียง คุณสมบัติ AI ประมวลผลที่ไหน หรือนโยบายการเก็บรักษาเป็นอย่างไร หากคุณใช้คุณสมบัติดังกล่าว ให้ตรวจสอบคู่มือของคุณสมบัติและเวอร์ชันนั้นแยกต่างหาก บทความนี้ไม่ได้ให้คะแนนหรือผลทดสอบที่แต่งขึ้นสำหรับคุณสมบัตินั้น
นอกจากนี้ เมทาดาทาในการส่ง เช่น ข้อมูลการกำหนดเส้นทาง ก็แตกต่างจากเนื้อหาเสียง การรักษาความลับของเสียงไม่ได้หมายความว่าการสื่อสารจะเป็นนิรนามอย่างสมบูรณ์
คำถามที่พบบ่อย
การถอดเสียงทำให้การเข้ารหัสข้อความต้นฉบับไร้ผลหรือไม่?
ไม่ได้เป็นเช่นนั้นโดยอัตโนมัติ การประมวลผลบนอุปกรณ์อาจทำได้โดยไม่ส่งเนื้อหาให้ตัวกลาง หากคุณตั้งใจส่งเนื้อหาให้บริการอื่น ขอบเขตความไว้วางใจสำหรับการประมวลผลนั้นก็จะกว้างขึ้น
ถ้าข้อความที่ถอดเสียงผิดล่ะ?
อย่าพึ่งพาข้อความอัตโนมัติเพียงอย่างเดียวสำหรับชื่อ ตัวเลข คำสั่งที่มีความอ่อนไหว หรือการตัดสินใจสำคัญ หากทำได้ ให้เทียบกับเสียงต้นฉบับและยืนยันกับผู้ส่ง ความผิดพลาดในการถอดเสียงเป็นคนละประเด็นกับการเข้ารหัส
การทำงานแบบออฟไลน์เป็นหลักฐานยืนยันความเป็นส่วนตัวอย่างสมบูรณ์หรือไม่?
ไม่ใช่ การทดสอบออฟไลน์เป็นเพียงข้อสังเกตที่มีขอบเขตจำกัด และไม่อาจแทนการตรวจสอบการส่งข้อมูลภายหลัง การจัดเก็บ การตั้งค่า และเอกสารได้
