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

 (github.com/mozilla)
6 คะแนน โดย GN⁺ 2026-05-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • 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 ถูกมองว่าเป็นหัวใจสำคัญ เพราะเป็นฟีเจอร์ในหน้าเว็บ และเบราว์เซอร์ไม่ควรเป็นฝ่ายเลือกโมเดลใดโมเดลหนึ่ง
    • ความสามารถนี้ตั้งอยู่บนรายละเอียดการ implement ในพื้นที่ที่เปลี่ยนเร็ว และยังไม่พร้อมสำหรับการทำมาตรฐาน
    • Extension จึงเป็นวิธีต้นทุนต่ำในการสำรวจรูปแบบการใช้งานจริงให้เลยขอบเขตข้อเสนอปัจจุบัน และทดลองฟีเจอร์ข้ามเบราว์เซอร์โดยไม่ต้องแบกรับต้นทุนการประสานให้ทั้งสามเอนจินปล่อยพฤติกรรมที่ยังไม่ตกผลึก

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

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

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

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

    • System prompt มักมีแนวโน้มถูกปรับซ้ำ ๆ ให้เข้ากับ quirk ของโมเดลที่ใช้งานอยู่
    • ใน system prompt สำหรับสร้างคำแนะนำระบบบ้านอัตโนมัติ โมเดล Gemini ในตอนแรกตอบออกมาแบบอเมริกันมากเกินไป และไม่เข้ากับเสียงลำโพงสำเนียงอังกฤษ
    • เมื่อเพิ่มใน system prompt ว่าต้องพูดด้วยสำเนียงอังกฤษ ก็กลับได้ผลลัพธ์อย่าง “a'waight guv'nor apples and pears” ซึ่งเป็นการเลียนแบบอังกฤษแบบอเมริกัน และต้องปรับเพิ่มอีกเพื่อให้ลดลงและใกล้เคียงอังกฤษจริงมากขึ้น
    • การชดเชยสำหรับโมเดลหนึ่งอาจกลายเป็นการชดเชยเกินไปในอีกโมเดล โดยปัญหาจะชัดขึ้นใน output format ที่มีการทำ brand 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') เพื่อขอ model ID, ชื่อ, เวอร์ชัน และบริษัทต้นทางของโมเดล
    • ตัวอย่างผลลัพธ์คือ 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • นักพัฒนาสามารถสร้างชุด system prompt สำหรับโมเดลเฉพาะ และบล็อกโมเดลที่ไม่รู้จักหรือแจ้งผู้ใช้ว่าอาจได้คุณภาพ output ต่ำ
    • แนวทางนี้ถูกมองว่าเป็นการย้อนกลับไปสู่ การแตกแขนงโค้ดแบบต้นยุค 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
  • ต้องการคงการมีส่วนร่วมและการหารือใน WebML CG ต่อไป พร้อมเดินหน้าการทดลองต่อเนื่อง เช่น sampling parameters ที่ทำงานร่วมกันได้
  • ฝั่ง Chrome ระบุแรงจูงใจว่าต้องการทำให้ Language Model ที่เบราว์เซอร์และ OS มีให้ เป็นตัวเลือกที่มีประโยชน์ต่อทั้งนักพัฒนาเว็บและผู้ใช้ โดยยังคงรักษาสุขภาพระยะยาวและความเป็นกลางของเว็บแพลตฟอร์ม
  • พื้นผิวของ Prompt API แสดง ความเข้ากันได้ ในระดับหนึ่งทั้งกับโมเดลของ Google และ Microsoft และมีการใช้ข้อจำกัดเชิงวัตถุกับคำตอบเพื่อให้ตรงกับ JSON schema หรือ regex ที่รู้จัก
  • ข้อจำกัดเหล่านี้ถูกใช้เป็นแนวทางบรรเทา เพื่อลดความจำเป็นของ hacks เฉพาะโมเดลในการรับมือกับ output ที่คาดเดาไม่ได้
  • โปรเจกต์ Chromium downstream กำลังสำรวจโมเดลทางเลือกและ framework backend อื่น ๆ รวมถึงงานเชื่อมต่อ Android MLKit ของ Microsoft และการทำต้นแบบระยะแรกเพื่อเชื่อมกับ 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
    • แม้จะระบุอย่างเด่นชัดในเอกสารว่าอะไรคือ “สิ่งที่ไม่ควรพึ่งพา” และอะไรคือ “สิ่งที่พึ่งพาได้” แต่หากทำตามคำแนะนำนั้นอย่างเคร่งครัด ก็ไม่ชัดเจนว่าจะยังเหลือ use case ที่ใช้งานได้จริงมากพอหรือไม่
    • ในทางปฏิบัติยังคงพึ่งพาพฤติกรรมของโมเดลที่ทดสอบแล้วบางส่วนได้ และถ้าโมเดลนั้นคือโมเดลของ Chrome เว็บไซต์ก็อาจขึ้นข้อความแนะนำให้ใช้ Chrome เวอร์ชันล่าสุด
    • ปัญหาคือ Google ระบุพื้นที่ที่ยังไม่สมบูรณ์ไว้อย่างกว้างขวาง แต่ยังมองว่ามาตรการบรรเทาปัจจุบันเพียงพอสำหรับการ shipping

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

  • ระบบอัตโนมัติของเบราว์เซอร์และ Lynx mode

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

  • Open web และ FOMO

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

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

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

  • การบรรเทาหลังเกิดปัญหาและการตอบสนองของ Chrome

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-05-01
ความเห็นจาก 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 แล้ว