- มีความเข้าใจกันอย่างแพร่หลายว่าเว็บแพลตฟอร์มทำงานได้เหมือนกันบนพื้นฐานของ API มาตรฐาน แต่ในความเป็นจริงมี API จำนวนมากที่พึ่งพา โครงสร้างพื้นฐานเฉพาะของผู้พัฒนาเบราว์เซอร์แต่ละราย
- Geolocation, Speech, Push, Payments, Passkeys ฯลฯ แม้ภายนอกจะดูเป็นมาตรฐานเว็บ แต่ภายในกลับเรียกใช้ บริการของ Google·Apple·Microsoft
- แม้จะเป็นการเรียก API เดียวกัน แต่ ความแม่นยำ·ความพร้อมใช้งาน·ความเข้ากันไม่ได้ตามภูมิภาค·นโยบายความเป็นส่วนตัว อาจต่างกันมากในแต่ละเบราว์เซอร์ และนักพัฒนามักพึ่งพาสิ่งเหล่านี้โดยไม่รู้ตัว
- โครงสร้างการทำมาตรฐานที่มีผู้เล่นรายใหญ่เป็นศูนย์กลาง ทำให้กำแพงในการเข้าสู่ตลาดของเบราว์เซอร์รายเล็กและระบบนิเวศโอเพนซอร์สสูงขึ้น และยิ่งเสริม ผลของการล็อกอินโดยพฤตินัย (lock-in)
- นักพัฒนาควรมอง API เหล่านี้เป็น ชั้น abstraction ของบริการจากผู้ขาย ไม่ใช่ ‘มาตรฐานเว็บ’ แบบบริสุทธิ์ และควรทำ การแจ้งเรื่องความเป็นส่วนตัว·การออกแบบทางเลือก·การทดสอบแยกตามเบราว์เซอร์ ควบคู่กันไป
การรับรู้ทั่วไปต่อเว็บแพลตฟอร์มกับโครงสร้างที่เป็นจริง
- เว็บแพลตฟอร์มมักถูกมองว่าเป็นระบบรวมศูนย์ที่อิงสเปกมาตรฐาน และคาดหวังว่าบนเบราว์เซอร์ที่ใช้เอนจินเดียวกันจะทำงานเหมือนกัน
- แต่ในความเป็นจริง API จำนวนมากพึ่งพา การติดตั้งใช้งานเฉพาะของแต่ละเบราว์เซอร์ และ บริการภายนอก·โครงสร้างพื้นฐานแบบปิด·ระบบภายในของผู้ขาย
- ต่างจากอินเทอร์เฟซที่เป็นมาตรฐาน รายละเอียดของการติดตั้งใช้งานจริงอาจแตกต่างกันมากตามการเลือกของผู้พัฒนาเบราว์เซอร์
Geolocation API และแหล่งที่มาจริงของข้อมูลตำแหน่ง
- Geolocation API ให้เพียงอินเทอร์เฟซมาตรฐาน แต่ข้อมูลตำแหน่งจริงถูกเก็บมาจากหลายช่องทาง
- ใช้บริการระบุตำแหน่งของระบบปฏิบัติการและ GPS
- ประเมินตำแหน่งจากข้อมูล Wi-Fi AP
- ค้นหาฐานข้อมูลตำแหน่งจาก IP address
- Chrome ใช้ Google Location Services, Safari ใช้ เซิร์ฟเวอร์ของ Apple, และ Firefox ตั้งแต่ปี 2024 ใช้ บริการของ Google
- เมื่อใช้งานข้อมูลตำแหน่ง ข้อมูลผู้ใช้อาจถูกส่งไปยังเซิร์ฟเวอร์ของผู้ขายรายใดรายหนึ่ง แต่ UI ของเบราว์เซอร์มักไม่ได้แสดงให้เห็นอย่างชัดเจน
- หาก การเข้าถึงบริการของผู้ขายถูกบล็อกในบางภูมิภาค ก็มีโอกาสที่ฟังก์ชันจะทำงานได้ไม่ปกติ
Speech Synthesis และโครงสร้างพื้นฐานการประมวลผลเสียง
- การสังเคราะห์เสียงของ Web Speech API ใช้เอนจินที่ต่างกันไปตามเบราว์เซอร์ ระบบปฏิบัติการ และสภาพแวดล้อมของอุปกรณ์
- Speech Synthesis API เป็นอินเทอร์เฟซมาตรฐาน แต่ข้อมูลเสียงถูกประมวลผลโดย เอนจิน TTS ของระบบปฏิบัติการ หรือ เซิร์ฟเวอร์คลาวด์
- Chrome ใช้ทั้งแบบ local และคลาวด์ ส่วน Safari ใช้เอนจินเสียงของระบบปฏิบัติการ
- เสียงคุณภาพสูงบางแบบต้องส่งข้อมูลผ่านออนไลน์เพื่อ ประมวลผลบนคลาวด์ ทำให้ ข้อมูลผู้ใช้ถูกส่งไปยังเซิร์ฟเวอร์
- มีความเสี่ยงที่ข้อความส่วนตัวหรือข้อมูลอ่อนไหว จะถูกส่งไปยังเซิร์ฟเวอร์ภายนอกโดยไม่ได้ตั้งใจ
- นอกจากนี้ เสียงที่เลือกไว้ในสภาพแวดล้อมการทดสอบอาจไม่มีอยู่ในสภาพแวดล้อมของผู้ใช้จริง
Speech Recognition และการส่งเสียงแบบเรียลไทม์
- Speech Recognition API ส่วนใหญ่พึ่งพา บริการรู้จำเสียงบนคลาวด์
- Chrome ใช้ Google, Safari ใช้ Apple, และ Edge ใช้บริการตระกูล Azure
- ตั้งแต่ Chrome 139 มีตัวเลือก
processLocally สำหรับประมวลผลในเครื่องได้ แต่ ไม่ได้เป็นค่าเริ่มต้น และยังเป็นความสามารถที่จำกัดอยู่ใน Chrome เท่านั้น
- ความแม่นยำและการรองรับภาษา แตกต่างกันตามคุณภาพโมเดลของแต่ละผู้ขาย
Passkeys และพื้นฐานจริงของ WebAuthn: ผูกติดกับระบบนิเวศของเบราว์เซอร์
- WebAuthn API ชูแนวคิดการยืนยันตัวตนแบบไร้รหัสผ่าน แต่ในทางปฏิบัติกลับผูกกับ โครงสร้างพื้นฐานของตัวจัดการรหัสผ่านในเบราว์เซอร์
- Chrome ใช้ Google Password Manager, Safari ใช้ iCloud Keychain, และ Edge ใช้ Microsoft Account
- Polypane เป็นต้น มีข้อจำกัดจาก Electron จึง ไม่รองรับ Passkey และต้องใช้ส่วนขยายอย่าง 1Password
- วิธีการจัดเก็บ·ซิงก์·กู้คืนข้อมูลรับรองถูกกำหนดทั้งหมดโดยการติดตั้งใช้งานของผู้ขายแต่ละราย
Payment Request API และการผูกติดกับผู้ให้บริการชำระเงิน
- Payment Request API ดูเหมือนเป็นมาตรฐาน แต่การชำระเงินจริง จะใช้งานได้หรือไม่ขึ้นอยู่กับพาร์ตเนอร์ของผู้ขาย
- Chrome ใช้ Google Pay, Safari ใช้ Apple Pay, Edge มีการรวมกับ Microsoft, และ Firefox ไม่รองรับ
- การรองรับตามภูมิภาค, UX และข้อกำหนดให้ผู้ใช้ตั้งค่าเพิ่มเติม ต่างกันไปในแต่ละเบราว์เซอร์
- ส่งผลให้จำเป็นต้องมี สัญญาแยกและตรรกะรองรับเฉพาะ สำหรับแต่ละวิธีชำระเงิน
Push API และเครือข่ายการแจ้งเตือนของผู้ขายแต่ละราย
- Push API เป็นมาตรฐาน แต่ โครงสร้างพื้นฐานเซิร์ฟเวอร์ ที่ใช้ส่งการแจ้งเตือนจริงแตกต่างกันไปในแต่ละเบราว์เซอร์
- Chrome/Edge ใช้ FCM, Safari ใช้ APNs, และ Firefox ใช้ Mozilla Push Service
- ข้อจำกัดการส่ง, ขนาดข้อความ, การจัดการออฟไลน์, นโยบายความเป็นส่วนตัว ต่างกันไปในแต่ละบริการ
- หากโครงสร้างพื้นฐานของผู้ขายมีปัญหา ก็อาจกระทบฟังก์ชัน push ทั้งหมดของเบราว์เซอร์นั้นได้
Media API, codec และปัญหา DRM
- Media Source Extensions(MSE) และ Encrypted Media Extensions(EME) เป็นมาตรฐาน แต่การรองรับจะแตกต่างกันตาม ลิขสิทธิ์ codec·DRM
- Chrome·Edge·Firefox ใช้ Widevine ขณะที่ Safari ใช้ FairPlay ซึ่งต่างก็พึ่งพา เทคโนโลยีแบบปิดโดยสมบูรณ์
- ผู้พัฒนาเบราว์เซอร์แต่ละรายมี codec และกลยุทธ์ที่ให้ความสำคัญต่างกัน
- จากค่าลิขสิทธิ์ DRM และข้อจำกัดทางเทคนิค ทำให้ เบราว์เซอร์ขนาดเล็กรองรับได้ยาก
การมาของ AI API ภายในเบราว์เซอร์: โครงสร้างผูกขาดรูปแบบใหม่
- Chrome กำลังทดลอง AI API ที่อิง Gemini Nano (สรุป·แปล·ตรวจแก้ ฯลฯ)
- แม้รันในเครื่องจึงไม่มีการส่งข้อมูลออกไป แต่ ขนาดโมเดล (ประมาณ 4GB) และ ความต้องการ GPU สูง อีกทั้งยังเป็น โมเดลกรรมสิทธิ์ของ Google
- เบราว์เซอร์อื่นต้องพัฒนาโมเดลของตนเอง และ เบราว์เซอร์ขนาดเล็กหรือโครงการโอเพนซอร์สไม่สามารถจัดหาและดูแลโมเดลระดับเดียวกันได้ จึงแข่งขันไม่ได้
- นี่คือ โครงสร้างการพึ่งพาผู้ขายรูปแบบใหม่ที่ขับเคลื่อนด้วย AI
ทำไมเรื่องนี้จึงสำคัญ
- ปัญหาด้านการพกพา: แม้เป็นโค้ดเดียวกัน แต่คุณภาพการทำงานอาจต่างกันตามเบราว์เซอร์·ภูมิภาค·สภาพแวดล้อม
- ความเสี่ยงด้านความเป็นส่วนตัว: ข้อมูลเสียง·ตำแหน่ง·push อาจถูกส่งไปยังเซิร์ฟเวอร์ของผู้ขาย โดยไม่ได้ตั้งใจ
- ความไม่สมดุลของการทำมาตรฐาน: บริษัทขนาดใหญ่เป็นผู้นำทั้งการเขียนสเปกและการติดตั้งใช้งาน พร้อมทั้งทำให้ โครงสร้างพื้นฐานของตนกลายเป็นเงื่อนไขที่แทบขาดไม่ได้ จน เบราว์เซอร์รายเล็กถูกกันออกไป
- ผลกระทบต่อนักพัฒนา: แม้ฟีเจอร์จะมีประโยชน์ แต่นักพัฒนาต้องตระหนักว่านี่คือ การพึ่งพาบริการ ไม่ใช่มาตรฐานล้วน ๆ
แนวทางที่นักพัฒนาควรใช้
- มอง API เป็นชั้น abstraction ของบริการจากผู้ขาย พร้อมเตรียมการทดสอบ·เอกสาร·เส้นทางสำรอง
- ออกแบบแบบ graceful degradation เพื่อรับมือกับความไม่สอดคล้องของฟังก์ชัน
- สร้างความโปร่งใสด้านความเป็นส่วนตัว: ระบุให้ชัดว่าอาจมีการส่งข้อมูลไปยังเซิร์ฟเวอร์ของบุคคลที่สาม
- จัดการการพึ่งพาผู้ขาย: ต้องมีแนวทางรับมือเมื่อบริการหยุดหรือมีการเปลี่ยนนโยบาย
- ทดสอบแยกตามเบราว์เซอร์·ภูมิภาค เพื่อตรวจสอบความต่างของคุณภาพ
- ลดการพึ่งพาผู้ขายให้มากที่สุดด้วย การเลือกเชิงกลยุทธ์
เว็บที่เราคิดว่าเป็น vs เว็บที่เป็นจริง
- แม้การเรียก API มาตรฐานจะเหมือนกัน แต่ การไหลของข้อมูล·ความแม่นยำ·การรองรับตามภูมิภาค·ความเป็นส่วนตัว·โครงสร้างต้นทุน ต่างกันไปในแต่ละเบราว์เซอร์
- การเรียก
navigator.geolocation.getCurrentPosition() ในทางปฏิบัติคือการ เรียกบริการระบุตำแหน่งของ Google หรือ Apple
- สเปกมาตรฐานกำหนดแค่อินเทอร์เฟซ ส่วนการทำงานจริง ขึ้นอยู่กับโครงสร้างพื้นฐานและนโยบายของผู้ขาย
- การเรียก API จึงเท่ากับการใช้เซิร์ฟเวอร์·นโยบาย·โมเดลธุรกิจของผู้ขายรายใดรายหนึ่ง
- เว็บแพลตฟอร์มยังคงทรงพลัง แต่ในความเป็นจริงมันมี โครงสร้างที่กระจัดกระจายและผู้ขายเป็นศูนย์กลางมากกว่าที่คิด
- นักพัฒนาต้องเข้าใจ เส้นแบ่งระหว่างมาตรฐานกับการติดตั้งใช้งานจริง ให้ชัดเจนและออกแบบตามนั้น
ยังไม่มีความคิดเห็น