การเอาตัวกลางพุชออกเปลี่ยนผู้ที่มีส่วนร่วมในการส่ง แต่ไม่ได้ทำให้เมทาดาทาการกำหนดเส้นทางหายไป
ความเป็นส่วนตัวของการแจ้งเตือน Android ไม่ได้ขึ้นอยู่กับว่าแชตเข้ารหัสหรือไม่เพียงอย่างเดียว บริการพุชสามารถกำหนดเส้นทางการแจ้งเตือนโดยไม่รับข้อความแชตที่อ่านได้ แต่ยังคงมีส่วนร่วมในการส่ง การเชื่อมต่อโดยตรงเอาตัวกลางรายนั้นออก แต่ไม่ได้ลบเมทาดาทาจากเซิร์ฟเวอร์ของแอปส่งข้อความหรือเครือข่าย
ดังนั้น การเปรียบเทียบที่มีประโยชน์จึงไม่ใช่ “FCM ทำทุกอย่างรั่ว ส่วนซ็อกเก็ตซ่อนทุกอย่าง” แต่คือข้อมูลใดไปถึงแต่ละฝ่าย การออกแบบที่เลือกทำงานเบื้องหลังได้เชื่อถือได้เพียงใด และผู้ใช้ตรวจสอบอะไรได้บ้าง
FCM ขนส่งอะไร
Firebase Cloud Messaging แยกข้อความแจ้งเตือนที่แพลตฟอร์มสามารถแสดงได้ ออกจากข้อความข้อมูลที่โค้ดแอปจัดการ เพย์โหลดอาจมีข้อความแจ้งเตือนที่อ่านได้ ข้อมูลเข้ารหัส หรือสัญญาณขั้นต่ำที่บอกให้แอปดึงข้อมูลอัปเดต การออกแบบเหล่านี้ส่งผลต่อความเป็นส่วนตัวต่างกัน ประเภทข้อความ FCM
เอกสาร Firebase ระบุการป้องกันด้วย TLS ระหว่างเซิร์ฟเวอร์ผู้ส่ง FCM และอุปกรณ์ แต่บอกว่า FCM ไม่ได้ให้ E2EE ระดับแอปพลิเคชันโดยอัตโนมัติ เพย์โหลดที่ละเอียดอ่อนต้องได้รับการป้องกันที่เหมาะสมเหนือชั้นการขนส่ง ในแอปส่งข้อความส่วนตัว การป้องกันนั้นต้องคงขอบเขตปลายทางตามที่แอปตั้งใจไว้ การเข้ารหัสข้อมูลที่เซิร์ฟเวอร์ซึ่งรู้ข้อความชัดเจนอยู่แล้วเป็นโมเดลความไว้วางใจอีกแบบ แนวทางการเข้ารหัส FCM
ตัวระบุการกำหนดเส้นทางพิสูจน์อะไร และไม่พิสูจน์อะไร
พุชที่เจาะจงเป้าหมายต้องมีตัวระบุอินสแตนซ์ของแอปที่เกี่ยวข้อง ซึ่งไม่ใช่สิ่งเดียวกับตัวระบุถาวรและสากลของบุคคล การลงทะเบียนอาจเปลี่ยนหรือหมดอายุได้ แนวทางปัจจุบันของ Firebase ครอบคลุมทั้งการลงทะเบียนตามการติดตั้งและโทเค็นแบบเดิม เอกสารจัดการการลงทะเบียน
ผู้ให้บริการพุชย่อมมีส่วนในการจัดการคำขอและการส่ง จึงมีประเด็นเมทาดาทาที่ต้องพิจารณา แต่รายละเอียดการเก็บรักษา การเชื่อมโยงบัญชี และขอบเขตการมองเห็นต้องอาศัยเอกสารหรือการวัด อย่าอนุมานว่าการแจ้งเตือนทั่วไปว่า “มีข้อความใหม่” เปิดเผยผู้ส่ง ผู้รับ และเครือข่ายความสัมพันธ์ทางสังคมทั้งหมดโดยอัตโนมัติ
การเชื่อมโยงจากเวลาอาจเป็นข้อกังวลในโมเดลภัยคุกคาม โดยเฉพาะเมื่อผู้สังเกตเห็นกระแสข้อมูลที่เกี่ยวข้องหลายชุด ความแม่นยำขึ้นอยู่กับข้อมูลที่สังเกตได้ การส่งเป็นชุด กิจกรรมเบื้องหลัง และปัจจัยอื่น “อาจให้เบาะแสได้” ไม่เท่ากับ “สร้างทุกบทสนทนาขึ้นใหม่ได้ง่าย ๆ”
เปรียบเทียบ FCM กับการซิงก์โดยตรง
| คำถามด้านการออกแบบ | พุชผ่าน FCM | การซิงก์เบื้องหลังโดยตรง |
|---|---|---|
| มีตัวกลางพุชของบุคคลที่สามหรือไม่? | มี | ไม่มีสำหรับการเชื่อมต่อโดยตรงนั้น |
| กันข้อความแชตที่อ่านได้ออกจากตัวกลางได้หรือไม่? | ได้ หากออกแบบเพย์โหลดอย่างเหมาะสม | แอปส่งข้อความยังต้องมี E2EE ที่เหมาะสม |
| เซิร์ฟเวอร์แอปเห็นข้อมูลการเชื่อมต่อหรือการส่งหรือไม่? | มักเห็น ขึ้นอยู่กับสถาปัตยกรรม | เห็น เพราะให้บริการไคลเอนต์โดยตรง |
| รับประกันการส่งทันทีหรือไม่? | ไม่ | ไม่ |
| ต้องทดสอบอะไร? | เนื้อหาเพย์โหลด วงจรชีวิตโทเค็น ความล่าช้า และกลไกสำรอง | ข้อจำกัด OS พฤติกรรมเชื่อมต่อใหม่ ต้นทุนแบตเตอรี่ และความล่าช้า |
การดึงข้อมูลเป็นระยะโดยตรงหรือซ็อกเก็ตลดการพึ่งพาผู้ให้บริการพุชได้ แต่ไม่ได้สร้างความนิรนามโดยอัตโนมัติหรือป้องกันไม่ให้ระบบปฏิบัติการ เครือข่าย หรือโครงสร้างพื้นฐานของแอปเองสังเกตเหตุการณ์ที่เกี่ยวข้องทั้งหมด
ทำไม WorkManager ไม่ใช่ช่องทางส่งข้อความทันที
Android จำกัดงานเบื้องหลังเพื่อจัดการทรัพยากร WorkManager จัดตารางงานแบบคงอยู่ภายใต้ข้อจำกัดเหล่านั้น การระบุชื่อมันในสถาปัตยกรรมไม่ได้หมายความว่าการเชื่อมต่อจะทำงานต่อเนื่องตลอดเวลา หรือทุกข้อความจะถึงทันที การตั้งค่าผู้ผลิต ข้อจำกัดแบตเตอรี่ และสถานะแอปมีความสำคัญ ข้อจำกัดงานเบื้องหลังของ Android
การปิดข้อจำกัดด้านพลังงานอาจเปลี่ยนความเชื่อถือได้และการใช้แบตเตอรี่ แต่อย่ายกเว้นข้อจำกัดในวงกว้างโดยไม่พิจารณา ทดสอบโหมดที่แอปรองรับบนอุปกรณ์จริง การนำองค์ประกอบ Google ออกไม่ได้สอนแอปให้ใช้กลไกส่งแบบใหม่โดยอัตโนมัติ บางฟังก์ชันอาจหยุดทำงาน
Livara อธิบายการแจ้งเตือนอย่างไร
เอกสารความปลอดภัยของ Livara ระบุว่าการแจ้งเตือนพุชของข้อความเข้ารหัสไม่มีรายละเอียดข้อความหรือชื่อ และระบุด้วยว่าบริการเก็บเมทาดาทาด้านการดำเนินงานและโทเค็นพุช สิ่งเหล่านี้เป็นคำกล่าวอ้างของผลิตภัณฑ์ ไม่ใช่หลักฐานว่า Livara ไม่ใช้ FCM หรือเมทาดาทาการส่งถูกซ่อนจากตัวกลางทุกฝ่าย
ควรอ่านเอกสารสาธารณะควบคู่กับโมเดลภัยคุกคาม บทความนี้ไม่ได้อ้างว่ามีตัวเลือกซิงก์โดยตรงที่ทดสอบแล้ว ข้อได้เปรียบด้านแบตเตอรี่ที่วัดแล้ว หรือนโยบายเก็บบันทึกเฉพาะใด ในกรณีที่ยังไม่มีการแสดงหลักฐาน
วิธีตรวจสอบการแจ้งเตือนในทางปฏิบัติ
ใช้ข้อความทดสอบที่ไม่ละเอียดอ่อน เปรียบเทียบสิ่งที่ปรากฏเมื่อโทรศัพท์ปลดล็อก ล็อก ออฟไลน์ และเชื่อมต่ออีกครั้ง ตรวจสอบพรีวิวบนอุปกรณ์ที่เชื่อมโยงและแอปที่มีสิทธิ์เข้าถึงการแจ้งเตือนแยกกัน การตั้งค่าหน้าจอล็อกควบคุมการแสดงผลในเครื่อง ไม่จำเป็นต้องเปลี่ยนเพย์โหลดพุชฝั่งเซิร์ฟเวอร์
สำหรับนักพัฒนา ให้ตรวจสอบเพย์โหลดทดสอบและบันทึกข้อมูลวินิจฉัยเพียงขั้นต่ำ วัดการส่งภายใต้สภาพแบตเตอรี่และการเชื่อมต่อที่สมจริง และระบุให้ชัดว่า “ส่งแล้ว” “รับคำขอแล้ว” “ส่งถึงแล้ว” และ “แสดงแล้ว” แต่ละคำหมายถึงอะไร เมื่อขอบเขตเหล่านี้ชัดเจน ทั้งความเป็นส่วนตัวและความเชื่อถือได้จะดีขึ้น
