JavaScript Beacon API ที่ออกแบบมาเพื่อส่งข้อมูลอย่างเชื่อถือได้เมื่อผู้ใช้ออกจากเว็บไซต์ ได้จุดประกายการถกเถียงอย่างรุนแรงในชุมชนนักพัฒนา แม้ว่าเทคโนโลยีนี้จะแก้ปัญหาทางเทคนิคที่แท้จริง แต่ผู้ใช้และนักพัฒนาจำนวนมากกำลังต่อต้านผลกระทบด้านความเป็นส่วนตัว
โซลูชันทางเทคนิค vs ข้อกังวลด้านความเป็นส่วนตัว
Beacon API ถูกสร้างขึ้นเพื่อแก้ไขปัญหาพื้นฐาน วิธีการแบบดั้งเดิมเช่น fetch() หรือ XMLHttpRequest มักจะล้มเหลวเมื่อผู้ใช้ปิดแท็บหรือนำทางออกจากหน้าเว็บ เบราว์เซอร์ให้ความสำคัญกับประสบการณ์ผู้ใช้มากกว่าการทำงานของ JavaScript ในระหว่างการ unload หน้าเว็บ โดยมักจะยกเลิกคำขอที่รอดำเนินการ Beacon API เสนอโซลูชันแบบ fire-and-forget ที่เบราว์เซอร์จัดการได้อย่างเชื่อถือได้มากกว่า
อย่างไรก็ตาม ความเชื่อถือได้นี้ทำให้มันกลายเป็นเครื่องมือที่ต้องการใช้สำหรับติดตามพฤติกรรมผู้ใช้ ส่วนขยายเบราว์เซอร์หลายตัวในปัจจุบันปิดใช้งาน API นี้โดยเฉพาะ และผู้ใช้สามารถปิดมันด้วยตนเองใน Firefox ได้โดยการตั้งค่า beacon.enabled เป็น false ผู้ใช้ Chrome ในปัจจุบันยังไม่มีตัวเลือกในตัวที่คล้ายกัน แม้ว่าส่วนขยายจากบุคคลที่สามจะเติมเต็มช่องว่างนี้
การรองรับของเบราว์เซอร์สำหรับการปิดใช้งาน Beacon API:
- Firefox: ตั้งค่า
beacon.enabled = falseใน about:config - Chrome/Chromium: ไม่มีตัวเลือกในตัว ต้องใช้ส่วนขยายจากบุคคลที่สาม
- Safari: สามารถใช้ได้ผ่านส่วนขยายเช่น StopTheMadness Pro
ชุมชนแบ่งแยกเรื่องการใช้งานที่ถูกต้อง
ชุมชนนักพัฒนายังคงแบ่งแยกเกี่ยวกับคุณค่าของ API ผู้บางคนโต้แย้งว่ามันมีจุดประสงค์ที่ถูกต้องนอกเหนือจากการติดตาม เช่น การรับประกันว่าการกระทำที่สำคัญของผู้ใช้เช่นการโหวตหรือการส่งฟอร์มจะไปถึงเซิร์ฟเวอร์แม้ว่าผู้ใช้จะนำทางออกไปอย่างรวดเร็ว คนอื่นๆ โต้แย้งว่ากรณีการใช้งานส่วนใหญ่เป็นประโยชน์ต่อผู้โฆษณามากกว่าผู้ใช้
ทางเลือกทางเทคนิคที่น่าสนใจหนึ่งอย่างเกิดขึ้นจากการอภิปราย การใช้ fetch() กับพารามิเตอร์ keepalive ที่ตั้งเป็น true สามารถบรรลุความเชื่อถือได้ที่คล้ายกันสำหรับสถานการณ์ page unload วิธีการนี้ให้การควบคุมมากขึ้นในขณะที่รักษาพฤติกรรม fire-and-forget ที่ทำให้ Beacon API น่าสนใจ
ทางเลือกทางเทคนิคสำหรับ Beacon API:
fetch()ที่มีพารามิเตอร์keepalive: true- การเชื่อมต่อ WebSocket สำหรับแอปพลิเคชันแบบเรียลไทม์
- Service Workers สำหรับการประมวลผลในพื้นหลัง
- เหตุการณ์
visibilitychangeเพื่อความน่าเชื่อถือบนมือถือ
ปัญหาความเชื่อถือได้บนมือถือ
บนอุปกรณ์มือถือ สถานการณ์กลายเป็นเรื่องซับซ้อนมากขึ้น เหตุการณ์ beforeunload ที่ใช้แบบดั้งเดิมสำหรับงานทำความสะอาด พิสูจน์แล้วว่าไม่เชื่อถือได้บนเบราว์เซอร์มือถือ นักพัฒนาแนะนำให้ฟังเหตุการณ์การเปลี่ยนแปลงการมองเห็นแทน โดยเรียก beacon เมื่อหน้าเว็บกลายเป็นที่ซ่อนแทนที่จะรอเหตุการณ์ unload ที่ชัดเจน
หมายเหตุทางเทคนิค: เหตุการณ์ visibilitychange เกิดขึ้นเมื่อผู้ใช้เปลี่ยนแท็บ ย่อเบราว์เซอร์ หรือทำให้อุปกรณ์เข้าสู่โหมดสลีป ทำให้เชื่อถือได้มากกว่าเหตุการณ์ unload บนแพลตฟอร์มมือถือ
ข้อจำกัดของ API:
- รองรับเฉพาะคำขอ POST เท่านั้น
- ขนาดข้อมูลที่ส่งได้มีจำกัด (ไม่ได้ระบุขีดจำกัดที่แน่นอน)
- ส่งคืนเฉพาะตัวบ่งชี้ความสำเร็จแบบ boolean เท่านั้น
- ไม่มีข้อมูลตอบกลับหรือการจัดการข้อผิดพลาด
- ไม่สามารถใช้งานใน Web Workers ได้
ข้อจำกัดการใช้งานและทางเลือก
Beacon API มาพร้อมกับข้อจำกัดที่น่าสังเกต รองรับเฉพาะคำขอ POST และจำกัดขนาดข้อมูล แม้ว่าขีดจำกัดที่แน่นอนยังคงไม่ชัดเจนในข้อกำหนด สำหรับแอปพลิเคชันที่ต้องการการส่งมอบข้อมูลสำคัญที่รับประกัน นักพัฒนาบางคนแนะนำให้รักษาการเชื่อมต่อ WebSocket ซึ่งให้การแจ้งเตือนทันทีเมื่อผู้ใช้ตัดการเชื่อมต่อ
อย่างไรก็ตาม WebSocket ใช้ทรัพยากรเซิร์ฟเวอร์มากกว่าและใช้แบตเตอรี่มือถือเร็วกว่า ทำให้ไม่เหมาะสำหรับสถานการณ์การวิเคราะห์ง่ายๆ การแลกเปลี่ยนระหว่างความเชื่อถือได้และการใช้ทรัพยากรยังคงมีอิทธิพลต่อการตัดสินใจการใช้งาน
การถกเถียงที่กำลังดำเนินอยู่สะท้อนความตึงเครียดที่กว้างขึ้นระหว่างประโยชน์ทางเทคนิคและความเป็นส่วนตัวของผู้ใช้ แม้ว่า Beacon API จะแก้ไขความท้าทายทางวิศวกรรมที่แท้จริง แต่ความเชื่อมโยงกับการติดตามทำให้มันกลายเป็นสายฟ้าแลบสำหรับนักเคลื่อนไหวด้านความเป็นส่วนตัว เมื่อเบราว์เซอร์พัฒนาและ API ใหม่เช่น fetchLater เกิดขึ้น สมดุลระหว่างความต้องการของนักพัฒนาและการควบคุมของผู้ใช้จะยังคงเปลี่ยนแปลงต่อไป
อ้างอิง: Say bye with JavaScript Beacon
 |
|---|
| สัญญาณนำทางเป็นสัญลักษณ์ของความตึงเครียดระหว่างเทคโนโลยีนวัตกรรมและข้อกังวลด้านความเป็นส่วนตัว ซึ่งแสดงให้เห็นถึงการอภิปรายที่ดำเนินอยู่ในชุมชนนักพัฒนา |