การคัดค้านของ Mozilla ต่อ Prompt API ของ Chrome

• Prompt API ซึ่งเปิดเผยโมเดลภาษาภายในเบราว์เซอร์เป็น Web API อาจมีประโยชน์ในรูปแบบทั่วไป แต่เสี่ยงเพิ่มปัญหาด้านการทำงานร่วมกัน เพราะกระตุ้นให้มีการพัฒนาที่ผูกกับ พฤติกรรมเฉพาะของแต่ละโมเดล
• หากนักพัฒนาปรับพรอมป์ต์และฟีเจอร์ให้เข้ากับ implementation เฉพาะอย่างเช่น Phi-4-mini ของ Edge ก็อาจทำให้เกิด คุณภาพที่ลดลง หรือการบล็อกการเข้าถึงเว็บไซต์บนเบราว์เซอร์หรือโมเดลอื่น
• Mozilla เห็นว่าควรผ่านการตรวจสอบใน userland เพิ่มเติม แทนที่จะส่งออกเป็น Web API โดยตรง และใช้ trial web extension API กับข้อเสนอ web extension ของกลุ่ม Web Machine Learning เป็นช่องทางรับฟีดแบ็กในระยะแรก
• หาก system prompt แพร่กระจายโดยปรับเข้ากับ quirk ของโมเดลใดโมเดลหนึ่ง โมเดลใหม่ก็อาจถูกมองว่าแย่ไปด้วย และอาจเกิดแรงกดดันให้เบราว์เซอร์ต้องใส่โมเดลของ Google หรือโมเดลที่เข้ากันได้กับ quirk เหล่านั้น
• ฝั่ง Chrome เสนอแนวทางบรรเทา เช่น การจำกัดรูปแบบคำตอบด้วย JSON schema และ regex, การหารือใน WebML CG และการทดลองกับโมเดลทางเลือก แต่จุดยืนของ Mozilla ต่อ Prompt API ยังถูกระบุว่าเป็น negative

---

การประเมินเชิงลบของ Mozilla ต่อ Prompt API

• Prompt API ถูกนำไปพิจารณาใน Mozilla standards-positions หลังจาก Blink ออก intent-to-prototype และมี explainer เชื่อมไปยัง webmachinelearning/prompt-api README
• ความเห็นของ Mozilla แทบจะเหมือนกับ Writing Assistance APIs #1067 โดยมองว่า Prompt API ในรูปแบบทั่วไปอาจมีประโยชน์ แต่ส่งเสริม พฤติกรรมเฉพาะของแต่ละโมเดล และเพิ่มความเสี่ยงด้านการทำงานร่วมกัน
• นักพัฒนาสามารถปรับพรอมป์ต์และฟีเจอร์ให้เหมาะกับโมเดลเฉพาะ และหากพัฒนาโดยเล็ง implementation อย่าง Phi-4-mini ของ Edge ก็อาจทำให้คุณภาพลดลงหรือเว็บไซต์ถูกบล็อกบนเบราว์เซอร์หรือโมเดลอื่น
• แทนที่จะปล่อยเป็น Web API ทันที ควร ตรวจสอบใน userland ให้นานกว่านี้ โดย trial web extension API ของ Mozilla และ ข้อเสนอ web extension ของกลุ่ม Web Machine Learning จะเป็นช่องทางเก็บฟีดแบ็กเบื้องต้น
• จากการอภิปรายที่เกี่ยวข้องและ #1067 จึงระบุจุดยืนต่อ Prompt API ว่าเป็น negative

เหตุผลที่เลือก Web Extension มากกว่า Origin Trial

• การเลือกโมเดลและจังหวะของการทำมาตรฐาน

  • ความสามารถในการเลือกโมเดลที่ตรงจาก model hub ถูกมองว่าเป็นแกนสำคัญ เพราะเป็นฟังก์ชันที่อยู่ภายในหน้าเว็บ และเบราว์เซอร์ไม่ได้บังคับเลือกโมเดลใดโมเดลหนึ่ง
  • ความสามารถนี้ตั้งอยู่บนรายละเอียดการพัฒนาที่เปลี่ยนเร็ว และยังไม่อยู่ในสภาพที่พร้อมจะทำมาตรฐาน
  • Extension จึงเป็นวิธีที่มีภาระต่ำในการสำรวจรูปแบบการใช้งานจริงนอกเหนือจากขอบเขตข้อเสนอปัจจุบัน และทดลองความสามารถข้ามเบราว์เซอร์โดยไม่ต้องแบกรับต้นทุนการประสานให้ทั้งสามเอนจินส่งฟีเจอร์ที่มีความหมายยังไม่ลงตัว

• ขอบเขตที่ผู้ใช้มองเห็นได้

  • การติดตั้ง Add-on เป็นสัญญาณให้ผู้ใช้รู้ว่ากำลังก้าวออกจากขอบเขตของฟีเจอร์เว็บทั่วไป ซึ่งในกรณีนี้คือ shared cross-origin storage
  • แนวคิดนี้ต่อเนื่องจากตรรกะคล้ายกับกรณี WebMIDI Add-On Gated ตำแหน่งเพิ่มเติม #704 ในบริบทอื่น
  • ข้อเสนอ extension ดังกล่าวจะเปิด API คล้าย Prompt ให้กับหน้าเว็บ และใช้ local inference กับโมเดลที่นักพัฒนาระบุ เพื่อให้ได้ทั้ง shared model storage และฟีดแบ็กผู้ใช้ระยะแรก

ความเสี่ยงจากการยึดติดกับโมเดลเดียว

• System prompt และ quirks ของโมเดล

  • System prompt มีแนวโน้มถูกปรับซ้ำไปเรื่อย ๆ ให้เข้ากับ quirk ของโมเดลที่กำลังใช้งาน
  • ใน system prompt สำหรับสร้างข้อความแนะนำระบบ home automation โมเดล Gemini ตอบออกมาแบบอเมริกันมากเกินไปในตอนแรก และไม่เข้ากับเสียงลำโพงแบบอังกฤษ
  • เมื่อเพิ่มข้อความใน system prompt ว่าพูดด้วยสำเนียงอังกฤษ กลับได้ผลลัพธ์ลักษณะล้อเลียนอังกฤษแบบอเมริกัน เช่น “a'waight guv'nor apples and pears” และต้องปรับเพิ่มอีกเพื่อให้ลดลงและใกล้เคียงอังกฤษจริงมากขึ้น
  • การชดเชยเพื่อโมเดลหนึ่งอาจกลายเป็นการชดเชยเกินไปในอีกโมเดล โดยเฉพาะเมื่อเป็น branded voice หรือรูปแบบเอาต์พุตที่ไม่สามารถอธิบายด้วย JSON schema หรือ regex ได้

• ภาระของโมเดลใหม่และการอัปเดตเบราว์เซอร์

  • หาก system prompt ที่ถูกปรับเข้ากับ quirks ของโมเดลเดิมแพร่หลาย โมเดลคู่แข่งใหม่ที่ดีกว่าก็อาจถูกนักพัฒนาและผู้ใช้มองว่าแย่
  • Mozilla และ Apple อาจตกอยู่ในสถานการณ์ที่ต้องไลเซนส์โมเดลของ Google หรือใส่โมเดลที่เข้ากันได้กับ quirk ของ Google เพื่อรักษาการทำงานร่วมกัน
  • แม้แต่ Chrome เองก็อาจอัปเดตโมเดลของตัวเองได้ยากขึ้นด้วยเหตุผลเดียวกัน

• การตรวจจับ model ID และการแตกแขนงตามเบราว์เซอร์

  • นักพัฒนาสามารถสร้างโมเดลด้วย LanguageModel.create() และถามข้อมูลอย่าง model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string') เพื่อขอ ID, ชื่อ, เวอร์ชัน และบริษัทต้นทางของโมเดล
  • ตัวอย่างผลลัพธ์ที่ได้คือ 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
  • นักพัฒนาสามารถทำชุด system prompt สำหรับโมเดลเฉพาะ และบล็อกโมเดลที่ไม่รู้จัก หรือแจ้งผู้ใช้ว่าคุณภาพเอาต์พุตอาจต่ำ
  • Mozilla มองว่าแนวทางนี้คือการถอยกลับไปสู่ การแตกแขนงโค้ดแบบยุคต้นทศวรรษ 2000 ที่ควรหลีกเลี่ยง

ปัญหานโยบายของ Google และความเป็นกลางของโมเดล

• ตาม เอกสาร Chrome ผู้ใช้ Prompt API ต้อง acknowledge Google Generative AI Prohibited Uses Policy ก่อน
• บางส่วนของนโยบายนี้ครอบคลุมเกินกว่าตัวบทกฎหมาย เช่น การห้าม “สร้างหรือเผยแพร่เนื้อหาที่ส่งเสริมเนื้อหาทางเพศอย่างโจ่งแจ้ง” และ “ส่งเสริมข้อกล่าวอ้างที่ทำให้เข้าใจผิดเกี่ยวกับรัฐบาลหรือกระบวนการประชาธิปไตย”
• การที่ Web Platform API ไปอยู่ในทิศทางที่ต้องปฏิบัติตามกฎการใช้งานเฉพาะของแต่ละ UA ไม่ใช่แนวทางที่ดี และอาจกลายเป็นบรรทัดฐานให้ API อื่นต้องมีข้อกำหนดเฉพาะ UA ตามมา
• หากผู้ใช้คลิก “summarize” ในคอมเมนต์บทความบนเว็บไซต์แล้วผลลัพธ์ละเมิดนโยบายของ Google ก็ไม่ชัดเจนว่าใครต้องรับผิด ระหว่าง ผู้ใช้ ที่กดปุ่ม, ผู้เขียนคอมเมนต์ ที่สร้างเนื้อหาละเมิด หรือ เจ้าของเว็บไซต์ ที่สร้างฟีเจอร์ส่งคอมเมนต์นั้นเข้าไปยัง UA LLM ของผู้ใช้
• นักพัฒนาอาจอยากรู้ว่ากำลังสื่อสารกับ LLM ใด เพื่อให้ปฏิบัติตามข้อกำหนดของโมเดลและหลีกเลี่ยงความเสี่ยงทางกฎหมายจากเจ้าของโมเดล และถ้าไม่รู้จักโมเดลนั้นก็อาจหมายถึงข้อกำหนดที่ไม่รู้จัก ทำให้การบล็อกการใช้งานเป็นทางเลือกที่สมเหตุสมผล
• มีอีกกระแสหนึ่งที่มองว่าเบราว์เซอร์เฉพาะรายไม่มีฐานที่จะเอาข้อกำหนดเช่นนี้ไปผูกกับนักพัฒนาเว็บไซต์ และปัญหาด้านนโยบายนี้ควรถูกแยกออกจากตัวข้อเสนอ API เอง

อัปเดตและแนวทางบรรเทาจากฝั่ง Chrome

• ฝั่ง Chrome Prompt API ได้แชร์ blink-dev I2S และอัปเดตบน ChromeStatus เกี่ยวกับ interoperability and compatibility risks
• Chrome ต้องการคงการมีส่วนร่วมและการอภิปรายใน WebML CG ต่อไป พร้อมการทดลองต่อเนื่อง เช่น sampling parameters ที่ทำงานร่วมกันได้
• ฝั่ง Chrome ระบุแรงจูงใจว่าต้องการทำให้ Language Model ที่เบราว์เซอร์และ OS มีให้ กลายเป็นตัวเลือกที่มีประโยชน์ต่อทั้งนักพัฒนาเว็บและผู้ใช้ โดยยังรักษาสุขภาพระยะยาวและความเป็นกลางของเว็บแพลตฟอร์มไว้
• พื้นผิวของ Prompt API แสดง ความเข้ากันได้ ได้ในระดับหนึ่งทั้งกับโมเดลของ Google และ Microsoft และกำลังใช้ข้อจำกัดคำตอบเชิงวัตถุวิสัยเพื่อให้เอาต์พุตตรงกับ JSON schema หรือ regex ที่กำหนด
• ข้อจำกัดเหล่านี้ถูกใช้เป็นแนวทางบรรเทา เพื่อลดความจำเป็นของ hacks เฉพาะโมเดลในการจัดการกับเอาต์พุตที่คาดเดายาก
• โปรเจกต์ Chromium ปลายน้ำกำลังสำรวจโมเดลทางเลือกและ framework backend อื่น ๆ รวมถึงการทำงานร่วมกับ Android MLKit ของ Microsoft และการทำ prototype ระยะแรกสำหรับการรวม foundational model ของ Apple
• ในช่วงทดลอง API ได้มีการปล่อยโมเดลหลายเวอร์ชันเพื่อทดสอบ และยังจำเป็นต้องอัปเดตและปรับปรุงโมเดลต่อเนื่อง รวมถึงกำลังสำรวจการรองรับ Gemma 4 open models รุ่นใหม่กว่า
• ยังมีการสำรวจ categorical sampling modes เพื่อจูนพฤติกรรมให้ทำงานร่วมกันได้ดีขึ้นบนสถาปัตยกรรมพื้นฐานที่แตกต่างกัน
• ข้อความใน Interoperability and Compatibility ของ blink-dev ระบุว่า ความแปรปรวนของพฤติกรรมและคำตอบเป็นสิ่งที่นักพัฒนาที่ใช้เทคโนโลยีนี้รับรู้อยู่แล้ว และ API นี้มีเป้าหมายเป็นกรอบการทำงานร่วมกันเพื่อการเข้าถึงเว็บแพลตฟอร์มที่สอดคล้องกันข้ามเบราว์เซอร์และโมเดล

เหตุผลสนับสนุนจากนักพัฒนาเว็บและคำวิจารณ์ต่อการส่งออก

• blink-dev intent to ship ระบุจุดยืนของนักพัฒนาเว็บว่า “Strongly positive” และเชื่อมเหตุผลไปยัง stakeholder feedback ใน explainer
• อย่างไรก็ตาม เหตุผลดังกล่าวถูกมองว่าไม่ได้สอดคล้องกับการประเมินว่า “Strongly positive” มากนัก

• รายการที่ถูกยกเป็นหลักฐาน

  • GitHub thread ที่มีคำตอบเชิงบวก 2 รายการ
  • โพสต์เดียวบน X
  • บทความบล็อกที่ไม่มีอยู่แล้ว ซึ่งขึ้นสถานะ Server Not Found
  • บทความบล็อกที่ยังเข้าถึงได้
  • แบบสำรวจ ดูเหมือนจะถามนักพัฒนาว่า API นี้ควรอยู่ใน extensions ได้หรือไม่ แต่ไม่ได้ระบุจำนวนผู้ตอบหรือกลุ่มตัวอย่าง
  • บทความบล็อกที่หายไปมีการแชร์สำเนาเก็บถาวรผ่าน Wayback Machine
  • แม้จะแสดงคำเตือนใหญ่ ๆ ว่า “ไม่ควรพึ่งพาอะไร” และ “พึ่งพาอะไรได้บ้าง” ในเอกสาร แต่ถ้าทำตามคำแนะนำนั้นจริง ขอบเขตการใช้งานที่เป็นไปได้ของ API ก็อาจแคบเกินไปจนไม่ชัดว่ายังเหลือ use case จริงหรือไม่
  • ในทางปฏิบัติ ยังพอพึ่งพาพฤติกรรมของโมเดลที่ทดสอบแล้วบางตัวได้ และถ้าโมเดลนั้นเป็นโมเดลของ Chrome เว็บไซต์ก็อาจขึ้นข้อความแนะนำให้ใช้ Chrome เวอร์ชันล่าสุดได้
  • ปัญหาคือ Google เองระบุพื้นที่ที่ยังไม่สมบูรณ์ไว้กว้างมาก แต่ยังมองว่ามาตรการบรรเทาที่มีอยู่ตอนนี้เพียงพอสำหรับการ shipping

การอภิปรายในคอมเมนต์: ทางเลือก การวัดผลกระทบ และการบรรเทาภายหลัง

• Browser automation และ Lynx mode

  • มีความเห็นว่าด้วย Hermes Agent และ Qwen3.6 ก็สามารถทำงานส่วนใหญ่ได้แล้ว และควรให้ความสนใจกับ browser automation API และ Lynx mode สำหรับแชต มากกว่า Prompt API
  • บาง workflow เป็นแบบที่มนุษย์ล็อกอินเข้าเว็บไซต์และทำให้ไฟล์มองเห็นได้ผ่าน AJAX extension ก่อน จากนั้น agent ใช้ chromedriver/webdriver เพื่อดาวน์โหลดเอกสาร ติดแท็ก และสรุป
  • กระบวนการนี้สามารถรวมอยู่ภายในเบราว์เซอร์ได้โดยไม่ต้องพึ่ง external POSIX shell
  • Lynx mode chat เป็นวิธีเปิดเผยสิ่งที่ agents เห็นได้อย่างรวดเร็ว และประหยัดทรัพยากรทั้งสองฝั่งเพราะไม่ต้องดาวน์โหลดหรือเรนเดอร์มีเดียทั้งหมด
  • ยังมีการพูดถึง robots tagging ระดับ HTML ที่ละเอียดขึ้น, การ handoff ระหว่าง Lynxmode shell กับเบราว์เซอร์เดิม และแนวทางให้ browser แบบขับเคลื่อนด้วย agent แสดงลิงก์สไตล์ Google AdWord แบบเก่าอย่างเลือกได้

• Open web และ FOMO

  • มีข้อโต้แย้งว่า open web ไม่ได้แข่งขันกับสิ่งอย่าง chat bot super apps ในแบบเดียวกัน และก็ไม่ได้กำลังจะหายไปไหน
  • อีกมุมหนึ่งเห็นว่าควรถามก่อนว่าตนเองต้องการเป็นตัวแทนของอะไร แทนที่จะถูกขับเคลื่อนด้วย FOMO อย่างต่อเนื่อง
  • ยังมีแนวโน้มที่ไม่เห็นด้วยกับความกังวลว่า ถ้าเว็บไม่สามารถรองรับ agentic computing ได้เร็วและมีประสิทธิภาพพอ ก็อาจทำให้ commerce หรือ journalism ย้ายออกจาก open web

• การ shipping ของ Chromium และการวัดผลกระทบ

  • approver คนหนึ่งในกลุ่ม blink API owner ของ Chromium บอกว่าแม้จะแชร์ความกังวลของ Mozilla แต่ก็ยังชอบแนวทางที่เปิดให้ทดลอง เรียนรู้จากความผิดพลาด และกระตุ้นการแข่งขัน
  • หากจะประเมินผลกระทบจริงในอนาคต จำเป็นต้องกำหนดผลลัพธ์ที่เป็นรูปธรรม และมีบริบทว่าการย้อนดูผลจริงหลัง 5–10 ปีของการตัดสินใจ shipping API ที่ถกเถียงกันอย่าง EME นั้นมีประโยชน์
  • ความเสียหายจากการที่เว็บไซต์ยึดติดกับโมเดลเฉพาะของ Google อาจประเมินได้จากจำนวนและขนาดของ site compat bugs ที่เบราว์เซอร์อื่นเจอเมื่อจะ shipping หรือจากลักษณะของบั๊กเมื่อ Chrome อัปเดตโมเดล
  • ยังมีข้อเสนอให้แยกว่า bug ประเภทไหนคือ “ทำให้โมเดลฉลาดขึ้น” กับประเภทไหนคือ “คงไว้ซึ่ง quirk แปลก ๆ” และรวบรวมด้วยการติด label ใน webcompat.com
  • ตาม blink-dev I2S Edge ก็ shipping API นี้กับโมเดลอีกตัวอยู่แล้ว จึงมี ข้อมูลตั้งต้น บางส่วนแล้ว
  • ตัวชี้วัดความเสียหายสำหรับความกังวลเรื่อง TOS คือมีการฟ้องร้องหรือข่มขู่ทางกฎหมายเกิดขึ้นจริงจากการละเมิดหรือไม่ และมีแนวคิดให้เก็บหลักฐานลักษณะนี้ไว้เป็นบันทึก

• การบรรเทาภายหลังและการตอบสนองของ Chrome

  • มีข้อโต้แย้งว่าแนวทางรอดูความเสียหายจริงนั้นใช้ได้ก็ต่อเมื่อหลังเกิดเหตุแล้วยังมีมาตรการบรรเทาที่มีความหมาย
  • เมื่อเว็บไซต์ยึดติดกับโมเดลเฉพาะของ Google แล้ว ก็มีการตั้งคำถามถึงทางเลือกต่าง ๆ เช่น การ unship ฟีเจอร์, การเปลี่ยนโมเดลให้ทำลาย site prompt ที่ถูกปรับจูนมากเกินไป, การสุ่มสลับโมเดล, หรือการทำมาตรฐานเปิดสำหรับ on-device model weights
  • มีความเห็นว่า หากมีหลักฐานว่าบราว์เซอร์อื่นต้องคัดลอก quirk แปลก ๆ ของโมเดล Chrome จริง ฝั่ง Chrome จากตำแหน่งผู้นำใน Chromium ก็จะผลักดันให้แก้ quirk นั้นให้พังไปเลย
  • ยังยกตัวอย่างก่อนหน้าว่า Mobile GMail เคยพึ่งพา WebKit border image quirks ที่มีบั๊ก และเมื่อ Firefox เริ่มรู้สึกว่าต้องคัดลอกตาม Chrome ก็เลือกแก้ฝั่งตัวเองจน GMail พัง ก่อนที่ GMail จะอัปเดตเร็วพอจนผู้ใช้แทบไม่ทันสังเกต

[GN⁺]

ความเห็นจาก Hacker News

• ประเด็นคัดค้านดูค่อนข้างชัดเจน: การผูกกันแน่นระหว่างพรอมป์ต์กับโมเดล และปัญหาเรื่องความเป็นกลางต่อโมเดลในข้อกำหนดการใช้งาน
  เหมือนกรณีส่วนตัวใน https://github.com/mozilla/standards-positions/issues/1213 ตอนสร้าง system prompt สำหรับการแจ้งเตือนระบบบ้านอัตโนมัติ Gemini ตอนแรกตอบออกมาอเมริกันเกินไป พอบอกว่าพูดด้วยสำเนียงอังกฤษ มันก็กลับกลายเป็นการเลียนแบบอังกฤษแบบอเมริกันงุ่มง่ามอย่าง “a'waight guv'nor apples and pears” จนต้องปรับต่ออีก
  ระหว่างกระบวนการนี้ system prompt จะถูกปรับให้เข้ากับโมเดลหนึ่งโดยเฉพาะ และเพราะโมเดลอื่นมี quirks คนละแบบ การชดเชยที่ใส่ไว้เพื่อโมเดลหนึ่งอาจกลายเป็นการชดเชยเกินไปสำหรับอีกโมเดลหนึ่ง

  • ผลลัพธ์คือฟังดูเหมือนกำลังเยาะเย้ยใน adversarial mode
  • ถ้านั่นเป็นเหตุผลที่ดีพอว่าจะไม่ควรรองรับความสามารถของ LLM ก็ควรสรุปต่อไปว่าไม่ควรใส่มันไว้ใน platform API ใดเลย แต่ตอนนี้มันถูกเพิ่มเข้าไปในแพลตฟอร์มมากมายแล้ว
    ความที่แต่ละโมเดลต่างกันเป็นคุณลักษณะหลักของเทคโนโลยีนี้ คล้ายกับที่ canvas มีขนาดต่างกันตามอุปกรณ์หรือการหมุนจอ, geolocation API แม่นยำไม่เท่ากัน, และเสียงของ Speech Synthesis ต่างกันไปตามอุปกรณ์
    สิ่งนี้ดูใกล้เคียงกับอารมณ์ anti-AI มากกว่าจะเป็นคำวิจารณ์เชิงสร้างสรรค์ ตอนนี้ควรมี permission UI และสักวันหนึ่งอาจมีระดับ IQ แบบ low/medium/high ด้วย แต่เอาจริงนักพัฒนาที่ใส่ใจก็คงพึ่งพาโมเดลเฉพาะอยู่ดี 90%
    เมื่อเวลาผ่านไปและความเกลียด AI ลดลง ผู้คนเห็นว่ามันมีประโยชน์ การที่ Firefox ไม่มีฟีเจอร์นี้อาจถูกมองว่าเป็นความล้มเหลวในแง่ อธิปไตยของข้อมูลส่วนบุคคล ถ้า TOU ที่เกี่ยวข้องของ Chrome เป็นปัญหา ก็ยิ่งเป็นเหตุผลที่ Firefox ควรใส่ฟีเจอร์นี้เข้ามาพร้อมข้อกำหนดของโมเดลที่ไม่มีปัญหา

• ตอนแรกไม่รู้ว่าใครเป็นคนเขียนบทคัดค้านนี้ แต่กลายเป็นว่าเป็น Googler เก่าจากทีม Chrome อย่าง Jake Archibald ที่ย้ายไป Mozilla แล้วมาเขียนคัดค้าน Chrome API เลยไม่แปลกที่คำวิจารณ์จะจัดระเบียบมาดี และคงโล่งใจที่คราวนี้ไม่ต้องเดินตามแนวพรรค

  • ขอบคุณนะ แต่คิดว่าตอนอยู่ Google เขาก็ไม่ได้เดินตามแนวพรรคอยู่แล้ว เพียงแต่นั่นทำให้การอยู่ข้างในยากขึ้นเรื่อย ๆ จนสุดท้ายต้องออกมา
    จากที่ฟังคนที่ยังอยู่ในทีมนั้น ดูเหมือนสถานการณ์ในแง่นี้จะแย่ลงแบบทวีคูณ
  • เขาคงคุ้นกับ standards-positions repo มาก และมันอ่านแล้วเหมือนการตั้งรับแบบคลาสสิกเวลาที่ Google พยายามดันอะไรบางอย่างโดยไม่รับฟังความคิดเห็นให้เพียงพอ
    แทนที่จะเสนอการแก้ไขกลับเป็นพยายามทิ้งทั้งก้อน ซึ่งถ้าถูกทิ้งไปก็ดูเหมือนคาดหวังว่าจะได้กลับมาเขียนใหม่แบบร่วมมือกันตั้งแต่ต้น ไม่ใช่เริ่มจากมุมของทีม Google Chrome แต่ผมไม่ค่อยเห็นกรณีแบบนั้นที่จบดี เลยรู้สึกว่าการเสนอแก้จุดที่ชัดเจนน่าจะดีกว่า

• อันนี้ผมคัดค้าน

  1. มันกลายเป็น ข้อมูล fingerprinting แบบใหม่ และเพราะหลอก fingerprinting script ได้ยาก จึงอาจถูกนำไปใช้ในทางที่ผิดสำหรับ “device verification” ไม่ควรมีความสามารถในการ “ยืนยัน” เบราว์เซอร์ และทุกคนควรสามารถจำลองเบราว์เซอร์ใดก็ได้
  2. LLM ใช้หน่วยความจำและ CPU มาก และเมื่อดูราคาของ RAM ตอนนี้ การอัปเกรดก็แพงด้วย ถ้าเว็บไซต์พึ่งพาโมเดลโลคัล อุปกรณ์ราคาถูกจะทำงานช้ามาก
  3. API ดูเหมือนออกแบบมาสำหรับ LLM เฉพาะอย่าง OpenAI
  4. มันอาจผลักคู่แข่งในตลาดเบราว์เซอร์ที่ไม่มีโมเดล AI ของตัวเองออกไป ถ้าเว็บถูกสร้างโดยคาดว่าใช้ Google Gemini เว็บไซต์อาจพังบนโมเดลอื่นหรือบนเบราว์เซอร์ของประเทศที่ไม่มีโมเดล AI และไม่ควรมีเบราว์เซอร์ “ชั้นหนึ่ง” กับ “ชั้นสอง”
     explainer บอกว่าสามารถประมวลผลแบบโลคัลได้โดยไม่ส่งข้อมูลไปที่ไหนเลย แต่ถ้าอย่างนั้นก็สงสัยว่าทำไม Google Gemini local model ถึงต้องมี Prohibited Use Policy ด้วย Google จะสนใจไปทำไมกับพรอมป์ต์และคำตอบที่ตัวเองไม่มีทางรู้
     ผมชอบแนวคิดการเข้าถึง LLM แบบออฟไลน์นะ แต่เว็บไซต์ไม่จำเป็นต้องให้เบราว์เซอร์ฝัง LLM ก็ได้ จะใช้ WebGPU หรือพัฒนา WebGPU ให้ดีขึ้นสำหรับการประมวลผลโมเดล ML ก็ได้ หรือไม่ก็ทุกคนใช้โอเพนซอร์ส LLM ตัวเดียวกันไปเลย
  • Google ก็แค่ชี้ไปทางที่มีเงินเหมือนแบคทีเรีย แล้วสะบัดแฟลเจลลัมมุ่งไปทางนั้นเท่านั้นเอง ไม่รู้จริง ๆ ว่าทำไมใครถึงคิดว่า Google จะทำสิ่งดี ๆ เพื่อเว็บหรือเพื่อมนุษยชาติ
  • ผมไม่เห็นด้วยอย่างแรงกับคำว่า “ไม่ควรสามารถยืนยันเบราว์เซอร์ได้” วงการ AI ได้ฉีกฉันทามติทางสังคมเรื่อง anti-scraping กับ anti-botting ที่มีมาก่อนโควิดจนไม่เหลือชิ้นดี
    ตอนนี้กลายเป็นเรื่องปกติไปแล้วว่า robots.txt ไม่ใช่ข้อบังคับและสามารถหลบเลี่ยงได้หมด ทำให้เว็บเปิดกลายเป็น dark forest ไปโดยพฤตินัย
    วิธีที่ตรวจสอบได้ว่า browser session ไม่ได้ถูกดัดแปลงหรือเป็น “trusted” มีแนวโน้มจะเกิดขึ้นในอนาคต แน่นอนว่ามันแย่มาก แต่สุดท้ายเราก็มีส่วนทำให้เป็นแบบนี้เอง
  • เรื่องความกังวลด้าน fingerprinting ผมคิดว่าทั้ง Chrome และแน่นอน Firefox น่าจะมีตัวเลือก “ห้ามดาวน์โหลด LLM เด็ดขาดและปิดความสามารถ LLM ทั้งหมด”
    เว็บไซต์อาจส่งคำขอเล็ก ๆ ไป fingerprint โมเดลตัวนั้นเองได้ก็จริง แต่ถ้าปิดได้ก็คงไม่ใช่ปัญหาใหญ่
    ในภาพกว้างกว่านั้นมีความกังวลแบบ “เว็บแพลตฟอร์มไม่ควรทำสิ่งนี้ได้เลย” จากมุมนี้ แม้ผู้ใช้จะปิดได้ ก็ยังจะมีเว็บไซต์แบบ “ไม่มี LLM ก็ไม่รองรับเบราว์เซอร์นี้” แล้วทำให้เว็บแย่ลงได้
    แต่สุดท้ายแล้วนั่นคือการตัดสินใจของผู้ดูแลเว็บไซต์ที่เลือกปิดเว็บหากไม่มี LLM ไม่ใช่ความผิดของแพลตฟอร์มหรือผู้ดูแลรักษาที่สร้างฟีเจอร์นี้ขึ้นมา คล้ายกับกรณีที่มันใช้ได้ดีบน Firefox แต่คนทำเว็บขี้เกียจทดสอบเลยปิดการรองรับไป
    เว็บคือแพลตฟอร์มแอปพลิเคชันที่ประสบความสำเร็จที่สุดในโลกซึ่งกำลังแข่งไม่ใช่กับ PDF แต่กับ SwiftUI ตัวเลือกแบบ “คงเว็บให้คงที่แบบปัจจุบันก็พอ” เป็นภาพฝัน ความจริงมีแค่ว่าเว็บต้องปรับตัวตามความต้องการผู้ใช้ที่เปลี่ยนไป หรือไม่ก็เว็บล้มเหลวแล้ว SwiftUI หรือ WinUI เข้ามาแทน ซึ่งอย่างหลังแย่กว่ามาก
  • อ่านคำตอบในเธรดนี้ไปเรื่อย ๆ แล้วก็ได้ข้อสรุปว่า: ยังไงพวกเขาก็จะทำอยู่ดี และคนที่พึ่งพา LLM อยู่แล้วหรือไม่มีความสามารถพอจะตัดสินอย่างเหมาะสมก็จะชื่นชมมัน
    https://news.ycombinator.com/item?id=47960596
    สรุปคือถึงเวลาต้องก้าวต่อไปแล้ว ต้องคิดถึงรูปแบบการแลกเปลี่ยนข้อมูลออนไลน์และการเล่นสื่อที่ดีกว่าเว็บเบราว์เซอร์ ถ้าเราเป็นสินค้า เครื่องมือที่เราใช้ก็ควรสะท้อนข้อเท็จจริงนั้นตรง ๆ แทนที่จะทำตัวเป็นพร็อกซีที่แอบส่งรายได้โฆษณาไปให้ผู้ปกครองที่ไม่น่าไว้วางใจ

• ยิ่งคิดก็ยิ่งเห็นด้วยกับฝั่งการออกแบบ API ของ Google มากกว่าในครั้งนี้
  การผูกกันแน่นระหว่างพรอมป์ต์กับโมเดล เป็นความกังวลจริงและเป็นปัญหาที่เจอทุกวัน แต่ถ้าวิธีแก้คือ API ที่ผูกพรอมป์ต์ซึ่งจะถูกประเมินให้แน่นขึ้นกับโมเดลในเบราว์เซอร์ของผู้ใช้ ไม่นานก็จะเกิดสถานการณ์แบบ “เราทดสอบพรอมป์ต์นี้กับ Gemini เท่านั้น ดังนั้นเว็บนี้ต้องใช้ Chrome”
  ที่แย่กว่านั้นคืออาจกลายเป็น “ไม่สามารถรู้ได้ว่าใช้โมเดล AI ตัวไหนอยู่” ถ้าเว็บไซต์ที่ทำในปี 2026 ไม่ได้รับการอัปเดตจนถึงปี 2030 นี่ก็เป็นเรื่องที่เกิดขึ้นได้มาก
  สิ่งนี้ยังโยงกับปัญหาข้อกำหนดการใช้งานที่วิศวกร Mozilla พูดไว้ด้านหลังด้วย ถ้าอยากให้มีเบราว์เซอร์ที่ไม่บังคับให้ผู้ใช้ต้องยอมรับข้อกำหนดของ AI model เฉพาะ เช่น เบราว์เซอร์ที่ใช้โมเดลโอเพนซอร์สดี ๆ การทำให้ fingerprinting ของ Big Models ทำได้ยากย่อมเป็นประโยชน์กว่า
  แน่นอนว่าหลายเว็บไซต์ก็คงเรียก isChrome() อยู่ดี ถึงอย่างนั้นผมก็ยังคัดค้านการเปลี่ยนแปลงที่เพิ่มวิธี fingerprinting เบราว์เซอร์โดยทั่วไป ข้อดีของการทำให้โมเดลไม่เปิดเผยตัวตนมีมากกว่าข้อเสียที่บางครั้งจะได้ผลลัพธ์ประหลาดเพราะความต่างเล็กน้อยระหว่างโมเดลอย่าง Gemini กับ Qwen

• ไม่เข้าใจว่าทำไม Google ถึงไม่ทุ่มทรัพยากรมหาศาลไปแก้จุดอ่อนเชิงโครงสร้างของสิ่งต่าง ๆ จำนวนมากที่เบราว์เซอร์ทำได้อยู่แล้ว แต่กลับชอบเติมของจุกจิกเข้าไปเรื่อย ๆ จนทำให้เบราว์เซอร์กลายเป็น Homermobile
  ทำไมไม่ไปโฟกัสกับพื้นฐานที่จะยกระดับคุณภาพชีวิตของทั้งเว็บแพลตฟอร์ม ตั้งแต่บล็อกสแตติก, อีคอมเมิร์ซ ไปจนถึงเว็บแอประดับล้ำสมัย
  https://simpsons.fandom.com/wiki/The_Homer

  • Google ไม่ได้ทำ Chrome เพื่อสร้างเว็บที่ดีกว่า การสร้างเบราว์เซอร์ดี ๆ เพื่อตัวเบราว์เซอร์เองคือการใช้เงินหลายพันล้านดอลลาร์ไปกับ goodwill และเป้าหมายของ Chrome คือการเป็นแพลตฟอร์มที่แทนที่ OS ของผู้ใช้เวลาที่ผู้ใช้ทำอะไรบางอย่างบนอุปกรณ์
    พวกเขาพยายามทำสิ่งนั้นโดยตรงผ่าน Android และ ChromeOS แต่ Chrome ก็ทำให้แม้แต่ผู้ใช้ทั่วไปบน Windows ใช้เวลาส่วนใหญ่อยู่ในโลกของ Google ได้
  • ถ้าอยากเลื่อนตำแหน่งที่ Google คุณต้องออก prompt API ให้ได้
  • การไม่ทำ prompt API จะทำให้เอาทรัพยากรไปลงกับอย่างอื่นที่ก่อนหน้านี้ไม่สำคัญขึ้นมาจริงหรือ? ฟังดูเป็น false dichotomy มากกว่า

• ผมมองว่า LLM และ API harness ในปัจจุบันยังไม่สุกงอมทางเทคนิคพอที่จะให้ API แบบนี้เข้าไปอยู่ในมาตรฐาน
  แต่ถ้าจะทำอย่างน้อยมันต้องเป็นสิทธิ์แบบ opt-in รายเว็บไซต์ และต้องมีวิธีระบุได้ว่ากำลังส่งพรอมป์ต์ไปยังโมเดลไหน แม้แต่การปรับ system prompt เล็ก ๆ น้อย ๆ ก็ควรถือเป็นส่วนหนึ่งของอัตลักษณ์นั้น
  ในฐานะผู้ใช้ ผมต้องมั่นใจได้ว่าเวลาเข้าเว็บสุ่ม ๆ จะไม่ถูก fingerprint ผ่าน API นี้โดยไม่ได้รับอนุญาต
  ในฐานะนักพัฒนา ผมต้องรู้ว่าผู้ใช้ใช้โมเดลอะไรอยู่ เพื่อจะได้มีตัวเลือกในการทำพรอมป์ต์แยกตามโมเดล

• “มีการคาดหวังมากขึ้นว่าเบราว์เซอร์และระบบปฏิบัติการจะเข้าถึง language model” งั้นเหรอ? จริงเหรอ?
  https://github.com/webmachinelearning/prompt-api/blob/main/R...

  • ผมคิดว่าทิศทางมันผิด ผมไม่อยากให้ OS หรือเบราว์เซอร์เข้าถึง LLM แต่ผมอยากให้ LLM เข้าถึงเบราว์เซอร์หรือ OS และตอนนี้มันก็กำลังเป็นแบบนั้นอยู่
    เพราะงั้นก็ควรมีแค่อินเทอร์เฟซสำหรับ LLM ที่ปิดไว้เป็นค่าเริ่มต้นและเปิดได้เมื่อผู้ใช้ต้องการ
    แบบนั้นก็จะไม่ถูก lock-in กับ LLM ที่ Apple ใส่มาใน OS และยังเลือกได้ด้วยว่าจะใช้ LLM provider ไหน เช่น ผมอยากให้ Claude เข้าถึงสิ่งที่ Apple Intelligence เข้าถึงได้ด้วย
  • ผมเป็นคนเขียนประโยคนั้นไว้เดิม แต่ไม่คิดว่าจะถูกตีความแบบนี้ สิ่งที่ตั้งใจจะสื่อไม่ใช่ความคาดหวังของผู้ใช้หรือนักพัฒนา แต่คือ แนวโน้มของอุตสาหกรรม ที่ผู้ผลิต OS และเบราว์เซอร์กำลังใส่หรือเตรียมใส่ LM
    ตอนนี้อาจเปลี่ยนจาก “คาดว่าจะเข้าถึง” เป็น “กำลังถูกใส่เข้ามา” ได้แล้ว ดูเหมือนหลายคนจะสับสน ถ้าทีมดูแลโปรเจกต์ช่วยอัปเดตก็น่าจะดี
  • macOS, iOS และ Windows มี local model API สำหรับนักพัฒนาภายนอก และ Chrome ก็กำลังทดลองอยู่ Firefox ใช้โมเดลสร้าง alt-text แต่ยังไม่มี API
    ตามทฤษฎีมันมีประโยชน์ ถ้านักพัฒนาพึ่งพาโมเดลโลคัลได้ มันก็จะ private และ decentralized มากขึ้น และลดความจำเป็นในการส่งเงินไปให้ AWS หรือ Anthropic ได้ด้วย มี use case ที่เดิมพันไม่สูงซึ่งมีความหมายก็ต่อเมื่อมันรันโลคัล, ออฟไลน์ และฟรี
    แต่ในทางปฏิบัติผมแทบไม่เห็นแอปเนทีฟไหนนำ Apple Foundation Models ไปใช้จริงเลย เลยอยากรู้ว่านักพัฒนา Mac/iOS มีอะไรจะมาแชร์ไหม
  • AI มอบพลังมหาศาลให้กับคนที่ทำได้แค่ bikeshedding AI เองก็มีโอกาสสูงที่จะเป็น bikeshed ด้วยเหมือนกัน แต่ก็มี use case ที่ถูกต้องอยู่บ้าง และมันยังมอบพลังให้คนพูดยืดเยื้อผลักดันไอเดียไร้ประโยชน์ได้นานกว่าการคัดค้านเสียอีก
    ตอนนี้ทุกอย่างดูเหมือนจะคาดหวัง bikeshed มากขึ้นเรื่อย ๆ CVE ก็คงคาดหวังเหมือนกัน
  • ดูเหมือนพื้นที่ผิวของ browser API จะยังไม่กว้างจนน่าอุจาดพอสินะ

• ข้อดีของ open protocol คือเราไม่จำเป็นต้องสนับสนุนหรือใช้ implementation ใด implementation หนึ่งโดยเฉพาะ แต่ถึงอย่างนั้น การผูกขาดเบราว์เซอร์ ก็ยังเป็นภาวะกลืนไม่เข้าคายไม่ออกต่อไป
  มีโปรเจกต์ดี ๆ อย่าง ungoogled chromium กับ Tor อยู่ แต่ปัญหาใหญ่สุดคือยังขาดทั้งเสียงที่พูดแทนคนทั่วไปและโปรเจกต์ที่เชื่อมกับคนหมู่มากได้
  ผู้ใช้ที่ไม่ค่อยรู้จำนวนมากไม่ได้สนใจทั้งต้นเหตุและวิธีสื่อสารสาร พวกเขาตอบสนองกับสิ่งที่ “สนุก” และมีแรงเสียดทานน้อย มากกว่าเสรีภาพและการควบคุม
  เราจะแก้เรื่องนี้ยังไง? จะทำให้เบราว์เซอร์เป็นของเรา ของผู้คน โดยผู้คน เพื่อผู้คน ได้ยังไง? คิดทีไรก็เศร้า

  • ถ้าคอมไพล์เบราว์เซอร์เองกลับจะแย่กว่าอีก ถ้าคุณอยากได้ Spotify หรือ Netflix คุณต้องใช้ Widevine ที่มี attestation และสุดท้ายก็ต้องจ่ายเงินให้ Google
    ถ้า Browser Agent string ไม่ใช่ Chrome หรือ Firefox ก็เตรียมเจอ Cloudflare CAPTCHA ไม่รู้จบหรือ 403 ได้เลย
  • ต้องเริ่มจากเลิกยัด Chrome เข้าไปในแอปพลิเคชัน “native” แล้วหันไปเรียน platform API ก่อน
    จากนั้นก็สร้างเว็บแอปบนพื้นฐานของ มาตรฐานเว็บ แทนที่จะทำตามที่ Chrome ทำ และไม่ควรมานั่งบ่นว่า Firefox กับ Safari ตามไม่ทัน
  • ง่ายมาก ใช้กฎหมายต่อต้านการผูกขาดแยกบริษัทยักษ์ใหญ่เทคทั้งหมดออก พวกนี้คือ robber barons แห่งยุคเรา
  • น่าเสียดายที่คำตอบแทบจะเป็น เงินทุนสาธารณะที่มีนัยสำคัญ อยู่เสมอ
  • เบราว์เซอร์ที่โอเคก็มีอยู่แล้ว และคนทั่วไปก็ใช้ Chrome คนที่แคร์ก็ย้ายไปใช้อันแรก ปัญหาที่ต้องแก้คืออะไร?
    คุณบอกว่าต้องมีโปรเจกต์ที่เข้าถึงคนทั่วไป แต่ในเวลาเดียวกันก็บอกว่าพวกเขาต้องการแรงเสียดทานน้อยมากกว่าเสรีภาพและการควบคุม มันดูขัดแย้งกัน คนทั่วไปเชื่อมโยงกับ less friction มากกว่าการควบคุม

• ผมสงสัยว่า use case ของ API นี้คืออะไร
  ประสบการณ์ของผมเวลาใช้ LLM แบบโลคัลคือเปิด llama-server ขึ้นมา ถ้าจำเป็นก็รันบนอีกเครื่อง แล้วตั้งค่าให้แอปพลิเคชันอื่นชี้ไปที่ เซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ตัวนั้นแทนบริการ OpenAI หรือบริการคล้ายกัน
  ผมไม่อยากให้เบราว์เซอร์เป็นคนสร้างหรือรัน LLM instance เพราะเครื่องนั้นอาจไม่มีทั้งความสามารถหรือทรัพยากรเหลือพอสำหรับการรัน LLM instance

• สงสัยว่านี่คือความต่างระหว่างคนรุ่นใหม่ที่ตอนนี้อยู่ไม่ได้แล้วถ้าไม่มี LLM กับคนรุ่นเก่าที่ไม่อยากถูกบังคับให้ต้องใช้ซูเปอร์คอมพิวเตอร์แค่เพื่อรันเว็บเบราว์เซอร์ที่ละเมิดความเป็นส่วนตัวหรือเปล่า
  สำหรับผมมันฟังดูเหมือนเป็นจุดเริ่มต้นที่ผู้คนจะหันไปค้นหาและพัฒนา ทางเลือกแทนเบราว์เซอร์/เว็บ

  • นี่ไม่ใช่กรณีที่ Mozilla ออกมาคัดค้าน AI
    แต่เป็นการอธิบายเหตุผลที่ชัดเจนและมีตรรกะว่าทำไม API ที่ถูกเสนอในรูปแบบปัจจุบันถึงไม่ดีต่อ การทำงานร่วมกันของเว็บ
  • ผมคิดว่าการคัดค้านตรงนี้ไม่เกี่ยวกับว่าชอบหรือเกลียด LLM แต่มันคือคำถามว่า API สำหรับเว็บเปิดข้อเสนอนี้สามารถทำให้เป็นจริงได้หรือไม่
    ส่วนตัวผมใช้ LLM ช่วยเขียนโค้ดและกับระบบบ้านอัตโนมัติ แต่ไม่ได้คิดว่า API นี้ดีต่อเว็บ
  • จากประสบการณ์ของผม คนหนุ่มสาวส่วนใหญ่เกลียด AI
  • ออกนอกเรื่องนิดหน่อย แต่ผมคิดว่าสิ่งที่ควรถูกทำใหม่อาจใกล้เคียงกับแนวคิดของระบบปฏิบัติการมากกว่าอินเทอร์เฟซของเบราว์เซอร์
    ผมไม่รู้คำตอบที่ถูก แต่หลังจากใช้ Niri/Wayland, GNOME, Windows และ Mac มาแล้ว ผมจะไม่กลับไปใช้ desktop แบบ non-tiling และ workflow การจัดการหน้าต่างเดสก์ท็อปที่ไม่ยึดคีย์บอร์ดเป็นหลักอีกแน่นอน
  • เรือ “เบราว์เซอร์ที่ต้องใช้ซูเปอร์คอมพิวเตอร์และละเมิดความเป็นส่วนตัว” แล่นออกไปตั้งแต่ปี 2008 แล้ว