เว็บไม่ต้องการผู้เฝ้าประตู: ข้อเสนอ “Signed Agents” ใหม่ของ Cloudflare

• นโยบาย Signed Agents ของ Cloudflare อ้างเรื่องความปลอดภัยเป็นเหตุผล แต่ในความเป็นจริงคือ ความพยายามแบบปิดที่ทำให้การเข้าถึงเว็บต้องได้รับอนุญาตก่อน
• ในเชิงประวัติศาสตร์ เว็บเติบโตมาได้ด้วย ความเปิดกว้างและมาตรฐาน และเทคโนโลยีปิดอย่าง Flash และ Silverlight ก็สุดท้ายถูกมาตรฐานเปิดอย่าง HTML5 แทนที่จนหายไป
• ต่อไปผู้ใช้งานหลักของเว็บจะเป็น AI agent และสิ่งนี้ต้องการ ระบบยืนยันตัวตนที่กระจายศูนย์และตรวจสอบได้ รวมถึงการให้สิทธิ์ตามหน่วยงาน
• โมเดลที่ถูกต้องคือการผสาน การมอบหมายสิทธิ์แบบอิงเชน + หลักฐานระดับคำขอ เพื่อให้เกิดการยืนยันตัวตนที่เชื่อถือได้และการควบคุมสิทธิ์ที่ละเอียด
• แทนที่จะให้บริษัทใดบริษัทหนึ่งถือกุญแจไว้ ควรรักษาเว็บที่ทุกคนสามารถเข้าร่วมและสร้างนวัตกรรมได้ผ่าน โปรโตคอลและมาตรฐานแบบเปิด

---

วิจารณ์ Signed Agents ของ Cloudflare

• Cloudflare เสนอระบบ Signed Agents ใหม่ แต่ในทางปฏิบัติมันคือ การควบคุมการเข้าถึงแบบอิงรายชื่อที่ได้รับอนุญาต
• การที่บริษัทบางแห่งเป็นผู้ตัดสินว่า agent ใดจะลงทะเบียนได้หรือไม่ เป็นเพียง ระบบอนุมัติโดยผู้ขาย ไม่ใช่โปรโตคอลอินเทอร์เน็ต
• สิ่งนี้ขัดกับธรรมชาติแบบเปิดของอินเทอร์เน็ต และ “การกรอกแบบฟอร์มเพื่อขออนุญาต” ไม่อาจกลายเป็นมาตรฐานได้

เว็บต้องเปิดกว้าง

• กลยุทธ์ “embrace and extend” ของ Microsoft ในยุค 90 ล้มเหลว และสิ่งนี้เกิดขึ้นได้เพราะเว็บยังคงความเปิดกว้างไว้
• รันไทม์แบบปิด อย่าง Flash และ Silverlight ท้ายที่สุดก็ถูกแทนที่ด้วยมาตรฐานเปิดอย่าง HTML5
• ประวัติศาสตร์พิสูจน์มาโดยตลอดว่า มาตรฐานเปิดช่วยเร่งนวัตกรรม

การมาถึงของยุค agent

• AI agent จะเป็นผู้ใช้หลักของเว็บในอนาคต โดยจะทำงานอย่าง ค้นหาข้อมูล ทำงานอัตโนมัติ ชำระเงิน และเจรจาสัญญา
• เส้นแบ่งระหว่างการกระทำของมนุษย์กับ agent จะเลือนรางลง และสิ่งนี้ทำให้ ระบบยืนยันตัวตนแบบอิงการมอบหมายสิทธิ์ กลายเป็นสิ่งจำเป็น

การยืนยันตัวตน (Authentication) และการให้สิทธิ์ (Authorization)

• การยืนยันตัวตน: ใครเป็นผู้กระทำ?
• การให้สิทธิ์: ทำอะไรได้บ้าง?
• Cloudflare สับสนระหว่างสองแนวคิดนี้ และพยายามใช้ “passport” เพื่อแก้ทุกปัญหา แต่สิ่งนี้เป็นไปไม่ได้โดยพื้นฐาน
• การยืนยันตัวตนที่ถูกต้องควรทำผ่าน เชนการมอบหมายสิทธิ์และลายเซ็นระดับคำขอ พร้อมใช้ กลไกการตรวจสอบแบบกระจายศูนย์ เช่น การเผยแพร่กุญแจสาธารณะบน DNS

การจัดการสิทธิ์

• ซอฟต์แวร์แบบเดิมใช้โมเดล OAuth scope ได้ผลดี เพราะมี ขอบเขตที่จำกัด
• แต่ agent เป็นเครื่องมืออเนกประสงค์ จึงต้องมี การให้สิทธิ์ตามงาน (Task-Scoped)
• ตัวอย่าง: สิทธิ์สำหรับ “ชำระค่าอาหารเย็น” และสิทธิ์สำหรับ “ดูประวัติการใช้จ่ายย้อนหลัง 3 เดือน” แม้เป็น agent ตัวเดียวกันก็ควรใช้ โทเคนคนละชุด
• เพื่อสิ่งนี้ สามารถใช้โทเคนแบบมีข้อจำกัดอย่าง Macaroons, Biscuits และเอนจินนโยบายอย่าง OPA/AWS Cedar

โปรโตคอลต้องมาก่อน ไม่ใช่ผู้เฝ้าประตู

• การยืนยันตัวตน การให้สิทธิ์ และการสร้างรายได้ ควรอยู่บน มาตรฐานแบบเปิดที่ทำงานร่วมกันได้ ไม่ใช่อยู่ภายใต้บริษัทใดบริษัทหนึ่ง
• หากมีเพียงไม่กี่บริษัทที่ตัดสินความถูกต้องของ agent เว็บก็จะเสื่อมสภาพเป็น สวนปิด (Walled Garden) ในไม่ช้า
• ดังนั้น จึงมีการเสนอ การมอบหมายสิทธิ์แบบอิงเชน หลักฐานระดับคำขอ และการให้สิทธิ์ตามขอบเขตงาน ในรูปแบบโอเพนซอร์ส เพื่อให้ทุกคนสามารถนำไปใช้งานได้

บทสรุป

• อนาคตของเว็บไม่ได้ขึ้นอยู่กับ “ใครควบคุมประตู” แต่ขึ้นอยู่กับ โปรโตคอลที่ทุกคนช่วยกันสร้างและต่อยอดนวัตกรรมได้

[GN⁺]

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

• ทุกคนฝันถึงเว็บที่เสรีและเปิดกว้างอย่างแท้จริง แต่ในความเป็นจริงกลับน่าผิดหวังที่คนที่มีบล็อกเล็ก ๆ หรือมีคอนเทนต์แทบไม่มีวิธีป้องกันตัวเองจากบอตเทรน AI เลย การหวังว่าจะแยก Agent ออกจากบอตเทรนนิงแล้วพวกมันจะเคารพ robots.txt จริง ๆ นั้นดูไม่สมจริง และถึงจะทำตาม robots.txt ก็ตาม แนวคิดการซื้อข้อมูลทางอ้อมโดยอ้างว่าเป็น licensed data ก็ยังคงอยู่ เว้นแต่จะเป็นบริษัทอย่าง Reddit, X, Google, Meta ที่มีทรัพยากรทางกฎหมายแทบไร้ขีดจำกัด คนทั่วไปแทบไม่มีอำนาจอะไรเลย และขอแนะนำวิดีโอที่น่าสนใจเกี่ยวกับเรื่องนี้ด้วย

  • เว็บที่เสรีและเปิดกว้างตามที่ทุกคนต้องการ กับความต้องการบล็อกบอตเทรน AI มันดูขัดแย้งกันเอง ถ้าเป็นเว็บที่เปิดให้ทุกคนจริง บอตเทรน AI ก็ควรเข้าถึงได้โดยไม่มีข้อยกเว้นเช่นกัน

  • (ว่าด้วยความฝันของเว็บเปิด) ความฝันเรื่องคอนเทนต์แบบเปิดบนอินเทอร์เน็ตเป็นเรื่องจริง บล็อกของฉันเปิดให้ใครก็ได้เข้าถึงอย่างอิสระ ไม่ว่าจะเป็นคนหรือเครื่อง และเซิร์ฟเวอร์ก็โฮสต์เองที่บ้านด้วย เลยไม่รู้สึกว่าจำเป็นต้องแยกมนุษย์กับ AI ถ้ากังวลว่าเว็บไซต์จะมีคนเข้าเยอะเกินไป จริง ๆ แล้วไม่ว่าจะเป็นคนหรือ AI ปัญหาก็คือทราฟฟิกที่มากเกินไปนั่นเอง ฉันแค่ใส่แนวทางขั้นต่ำด้วย robots.txt เพื่อไม่ให้บอตวนลูป แล้วก็เปิดให้ crawl ได้อย่างอิสระ Amazonbot ก็แวะเข้าไซต์ฉันบ่อย และยินดีต้อนรับเสมอ

  • คิดว่าเราควรพัฒนาซอฟต์แวร์เสรีเพื่อต่อสู้กับซอฟต์แวร์ที่เป็นปฏิปักษ์ บริษัทยักษ์ใหญ่กำลังพัฒนา AI agent ที่เป็นปฏิปักษ์ ดังนั้นแฮ็กเกอร์ฝีมือดีควรพัฒนา anti-AI-agent มารับมือ ไม่เห็นด้วยกับความพ่ายแพ้นิยมแบบ “พวกเราไม่มีอำนาจ”

  • ชี้ให้เห็นความจริงที่ว่าใน Hacker News แห่งนี้มีวิศวกรจากบริษัทยักษ์ใหญ่ด้านไอทีมากมาย แต่กลับไม่เคยโวยเรื่องความเป็นส่วนตัวและธรรมาภิบาลข้อมูลในงานของตัวเอง เอาแต่ส่งเสียงเรื่องอื่น ๆ ถ้าต้องการกระจกไว้ส่องเพื่อทบทวนตัวเอง ฉันยินดีซื้อ

  • ไม่เข้าใจว่าทำไมถึงมีคำถามว่าต้องปกป้องบล็อกเล็ก ๆ หรือคอนเทนต์จากบอตเทรน AI หรือไม่ ถ้าการสร้าง HTML พื้นฐานยังยากจนต้องใช้เฟรมเวิร์กที่หนักและซับซ้อน แล้วทำให้กินทรัพยากร CPU มากเกินไป นั่นต่างหากคือปัญหาจริง หรือถ้าคิดว่างานเขียนออนไลน์ของตัวเองคือเส้นทางสู่ความมั่งคั่งและชื่อเสียงแบบครีเอเตอร์ ก็คงน่ากังวลอยู่ แต่ถ้าไม่ใช่ ก็คิดว่าไม่มีปัญหาอะไรตั้งแต่แรก

• ในทางปฏิบัติคิดว่า “เว็บ” ไม่ได้เปิดมานานมากแล้ว ปฏิสัมพันธ์ การโพสต์ และการกระจายข้อมูลส่วนใหญ่เกิดขึ้นหลังการยืนยันตัวตน(ล็อกอิน) โซเชียลรายใหญ่ สำนักข่าว และอื่น ๆ ส่วนมากจำกัดหรือบล็อกการเข้าถึงที่ไม่ได้ยืนยันตัวตน บล็อกมีสัดส่วนน้อยมากของข้อมูลทั้งหมดที่คนทั่วไปบริโภค

  • ไม่เห็นด้วยกับคำกล่าวที่ว่า “เว็บไม่เปิดอีกต่อไปแล้ว” เว็บไม่จำเป็นต้องเพิ่ม gatekeeper และถ้ามีมากอยู่แล้ว ก็ควรลดลงมากกว่า

• ฉันเองก็ไม่ได้สนใจ AI Agent โดยตัวมันเอง ถ้ามีผู้ใช้จริงอยู่เบื้องหลังฉันก็โอเค แต่สิ่งที่ไม่พอใจมากคือ Meta, Perplexity, OpenAI crawl เว็บฉันอย่างหนัก AI crawling ใช้ทรัพยากรมากกว่าทั้งผู้ใช้จริงและ Google Search เสียอีก อาการที่ CPU core ถูกผูกไว้กับ AI crawling นี่น่าหงุดหงิดมาก

  • ฉันก็มีแอปส่วนตัวหลายตัวที่ออนไลน์อยู่ และเดือนที่แล้วมี AI bot ตัวหนึ่งดูดข้อมูลไป 1.6TB จนต้องเปิดฟีเจอร์ Cloudflare AI bot protection เพราะมันยิงรีเควสต์มาไม่หยุดเกินวันละ 1.3 ล้านครั้ง รับไม่ไหวจริง ๆ

  • บางเว็บไซต์การตลาดของฉันโดนรีเควสต์ระดับ 200~300 ครั้งต่อวินาที แถมยังสุ่มสร้าง URL ที่ไม่มีอยู่จริงขึ้นมาเรียกอีก คุมไม่ได้เลย

  • ชวนสงสัยว่าบริษัท AI ทำให้เกิด CPU cycle มากแค่ไหนจากการ crawl เว็บ ปกติพูดถึงผลกระทบต่อสิ่งแวดล้อมของ AI ก็มักนับแค่การเทรนหรือการ inference ตอนให้บริการ แต่จริง ๆ ต้องนับภาระเพิ่มจากการ crawl เว็บด้วย ถ้าจะเทียบให้แม่น ควรดูเทียบกับกรณีที่มนุษย์เข้ามาทำเอง และออกแบบให้บอตสร้างทราฟฟิกได้มีประสิทธิภาพกว่า เช่น เรียก tracker, รูปภาพ และองค์ประกอบเสริมให้น้อยที่สุด แล้วดึงเฉพาะสิ่งที่จำเป็นต่อคำถามเป้าหมาย แบบนั้นภาระ CPU รวมอาจน้อยกว่าการที่มนุษย์ทั้งโลกเปิดเว็บผ่านเบราว์เซอร์เองเสียอีก

  • ฉันก็เหมือนกัน การใช้ AI agent ถ้ามีผู้ใช้อยู่เบื้องหลังจริง และไม่เข้าถึงแบบผิดปกติหรือมากเกินไป ก็ไม่ได้ใส่ใจนัก (แม้ฉันจะไม่ได้ตั้งใจให้มีการใช้ AI agent กับสิ่งของฉันก็ตาม จะใช้ยังไงก็ไม่ว่า) แต่ไม่ชอบการ crawl มากเกินไป อีกเรื่องที่สำคัญกว่าคือ อาจมีคนแค่ใช้ curl ดาวน์โหลดไฟล์เดียว หรือใช้เบราว์เซอร์ข้อความอย่าง Lynx ซึ่งควรรองรับสถานการณ์แบบนี้ต่อไป

  • Cloudflare แยกความต่างระหว่าง agent ที่ “ผู้ใช้พยายามเรียกใช้” กับการ crawl แบบหว่านแหเพื่อเก็บข้อมูลเทรนนิงที่ไม่ได้มีผู้ใช้จริงอยู่เบื้องหลัง คำขอส่วนใหญ่ที่ Meta, Perplexity, OpenAI ส่งมาคือฟังก์ชันค้นหาเว็บที่ทำงานตามพรอมป์ของผู้ใช้จริง ไม่ได้ถูกนำไปใช้เทรน LLM รุ่นถัดไป Cloudflare ทำให้เส้นแบ่งระหว่างสองอย่างนี้คลุมเครือ และในทางการก็ชูเรื่อง “ปกป้องครีเอเตอร์” แต่แท้จริงคือสร้างระบบเก็บ “ค่าผ่านทาง” จาก LLM provider เพื่อหากำไรให้ตัวเอง สุดท้ายจึงคิดว่าไม่ได้ขับเคลื่อนด้วยความเป็นธรรม แต่เป็นแรงจูงใจทางการเงิน

• ฉันใช้เบราว์เซอร์หายากที่ไม่เปิดเผยข้อมูลส่วนตัวมากนัก แต่ในสายตา Cloudflare ฉันก็ดูไม่ต่างจากบอต คิดว่าในสภาพแวดล้อมที่โฮสต์(เจ้าของเว็บไซต์)เป็นผู้ตัดสินสิทธิ์การเข้าถึง ความเป็นส่วนตัวไม่อาจมีอยู่ได้ ฉันเห็นด้วยกับ rate limiting เพื่อป้องกันภาระบนเซิร์ฟเวอร์ แต่การบล็อกการเข้าถึงแบบอัตโนมัติโดยตัวมันเองนั้นแทบเป็นไปไม่ได้ และถ้าบล็อกแบบนี้ไปเรื่อย ๆ สุดท้ายผู้ใช้จริงก็เข้าถึงลำบากด้วย

  • อยากรู้ว่าตอนนี้คุณโดนบล็อกบ่อยเพราะ Cloudflare หรือ turnstile หรือเปล่า ที่พูดไว้ข้างบนก็บอกใบ้แล้ว แต่อยากยืนยันให้ชัด

  • ถ้าคนที่อยู่ในประเทศเผด็จการจำเป็นต้องใช้ VPN เพื่อความเป็นส่วนตัวและเสรีภาพ อินเทอร์เน็ตก็จะกลายเป็นนรก captcha ที่มีบริษัท 2-3 เจ้าเป็นคนคุม เวลาฉันใช้บอตที่เขียนเองเข้าถึงเว็บที่ป้องกันด้วย Cloudflare ยังมีปัญหาน้อยกว่าการใช้ VPN กับเบราว์เซอร์เน้นความเป็นส่วนตัวเพื่อท่องเว็บปกติด้วยซ้ำ และถ้า Microsoft เป็นคนรับหน้าที่ gatekeeping เว็บจริง ๆ ก็คงแย่กว่านี้มาก โดยเฉพาะถ้าใช้ VPN แล้วต้องผ่าน captcha ของ Microsoft ต้องตั้งใจเต็มที่เกิน 5 นาทีราวกับจะเขียนวิทยานิพนธ์ถึงจะผ่านได้

  • เจ้าของเว็บไซต์ก็มีสิทธิ์ของตัวเองเหมือนกัน การบอกว่าไม่ควรเลือก gatekeeping เพื่อความยั่งยืนทางการเงินของการดำเนินงานนั้นเป็นข้อเรียกร้องที่เกินจริง

  • ฉันเองก็ใช้เบราว์เซอร์หายากและมักติด bot blocker เหมือนกัน แต่ก็คิดว่าโฮสต์มีสิทธิ์จัดการคำขอของฉันได้อย่างอิสระเช่นกัน โดยเฉพาะเว็บไซต์ภาครัฐที่ควรมีหน้าที่ให้บริการทุกคนอย่างเป็นธรรมมากกว่าเดิมมาก

• ถ้ามีทางเลือกที่เปิดกว่านี้และดีกว่านี้ก็อยากฟังนะ แต่สิ่งที่ Cloudflare ทำตอนนี้แก้ปัญหา AI bot ในโลกจริงได้ค่อนข้างดี ก่อนหน้านี้ก็พยายามบล็อกด้วย IP หรือ user agent มาแล้วแต่มีข้อจำกัด และจริง ๆ ปัญหาความปลอดภัยอื่น ๆ ก็ถูกแก้ด้วยแนวทางที่รวมศูนย์พอสมควรแบบนี้มานานแล้ว ทั้ง certificate authority ก็ไม่ใช่ระบบเปิด และผู้ให้บริการ attestation ก็ไม่ใช่ระบบเปิดเช่นกัน แต่ก็ยังใช้งานได้ดี

  • ถ้าอยากได้โซลูชันที่เปิดกว่านี้ กฎระเบียบอาจเป็นคำตอบ ทำให้คำขอจาก crawler ที่เว็บไซต์ไม่ได้อนุญาตอย่างชัดเจนใน robots.txt เป็นสิ่งผิดกฎหมาย และให้หน่วยงานบังคับใช้ลงมือโดยตรง ถ้าเจ้าของเว็บไซต์พิสูจน์ bot traffic ได้ ก็แจ้งรัฐเพื่อปรับเป็นเงินก้อนโตได้ ผู้ให้บริการคลาวด์ก็อาจถูกบังคับให้เก็บบันทึกว่าใครใช้ IP ไหน วิธีนี้ไม่ใช่คำตอบ 100% แต่ถ้าบังคับใช้อย่างดี ก็น่าจะมีผลยับยั้งได้แรงพอ

  • วิธีนี้อาจไม่ใช่คำตอบที่ดีที่สุด แต่ในทางปฏิบัติก็เป็นโซลูชันที่พอใช้ได้ แม้จะมีเสียงวิจารณ์เรื่องการรวมศูนย์มาก แต่ถ้า Cloudflare ดึงทั้งบริษัท AI รายใหญ่และ CDN ต่าง ๆ เข้าร่วมได้สำเร็จ มันก็อาจแข็งตัวเป็นมาตรฐานโดยพฤตินัยได้

  • ใบรับรองไม่ได้บล็อกคนเพียงเพราะเข้าใจผิดว่าเป็นบอต

  • กลับกันคิดว่า AI poisoning น่าจะเป็นการป้องกันที่ได้ผลกว่า คือจงใจผสมข้อมูลผิด ๆ เพื่อรบกวน AI และ Cloudflare เองก็อาจทำบริการที่จงใจส่งข้อมูลผิดให้ AI bot ได้ด้วย

  • ความจริงแล้วก่อนจะมี Let's Encrypt นั้น CA มักถูกใช้แค่กับเว็บไซต์ธุรกิจทั่วไป และมักแค่บางหน้าอย่างหน้าล็อกอิน ถ้าไม่มีนโยบายเปิดของ Let's Encrypt ข้อมูลส่วนตัวของพวกเราก็คงยังถูกเปิดให้ ISP หรือผู้โจมตีแบบ man-in-the-middle เห็นอยู่ ผู้ให้บริการ attestation เองก็ไร้น้ำยา เช่น แม้ช่องโหว่อุปกรณ์จะถูกเปิดเผยอย่างกว้างขวางก็ยังปฏิเสธจะเพิกถอนการรับรองเพราะเหตุผลทางธุรกิจ สรุปคือดูเหมือนการถกเถียงส่วนใหญ่ยังหาทางเลือกจริง ๆ ไม่เจอ การที่ Cloudflare กลายเป็น gatekeeper ของอินเทอร์เน็ตเป็นทางออกที่แย่ แต่ตัวปัญหาจริงร้ายแรงกว่านั้นมาก โซลูชันแบบกระจายศูนย์เต็มรูปแบบก็มีอยู่แล้ว(เช่น remote attestation, โมเดลจ่ายเงินต่อการเข้าชมหรือสมัครสมาชิก, ไฟร์วอลล์ self-hosted) ทัศนคติที่เมินผลข้างเคียงของ AI แล้วบอกให้แค่จ่ายต้นทุน คือสิ่งที่ยิ่งทำให้ Cloudflare เติบโต ถ้า ISP และรายอื่น ๆ ไม่เพิกเฉยต่อปัญหาอย่าง spoofing, DDoS, botnet ตั้งแต่แรก Cloudflare ก็คงเป็นแค่คู่แข่งอีกเจ้าหนึ่งแบบ Akamai เท่านั้น

• โลกนี้มี gatekeeper มากเกินไปอยู่แล้ว ความพยายามจะเพิ่ม gatekeeper ใด ๆ อีกควรถูกมองว่าเป็นการกระทำเชิงรุก Cloudflare และ Google ต่างก็ผลักดันสถานะ gatekeeper ของตัวเองให้แข็งแรงขึ้นเรื่อย ๆ ถ้าแนวโน้มนี้ยังดำเนินต่อไป ก็อยากเห็นทั้งคู่พังลงอย่างสิ้นเชิง

  • หลายบริษัทกำลังพยายามออกทางแก้ปัญหา AI bot และถ้า Cloudflare ถูกเลือก มันจะทำเงินมหาศาล แต่ต่อให้ Cloudflare ถอย ปัญหาก็ไม่หายไป แค่จะถูกแทนที่ด้วยทางเลือกแย่ ๆ ของบริษัทอื่น gatekeeping เป็นทางเลือกที่เจ้าของเว็บไซต์เลือกได้เองอยู่แล้ว(เช่น paywall, ระบบตรวจจับบอตที่ทำเอง, การยืนยันตัวตนด้วย ID ฯลฯ) Cloudflare ก็มีบริการเหล่านี้อยู่แล้ว และถ้าถูกทำให้เป็นมาตรฐาน ตัวเลือกก็จะเพิ่มขึ้น ตลาดก็จะเปิดกว้างขึ้นด้วย(รวมทั้งผลข้างเคียง) เสรีภาพของเว็บเปิดที่แท้จริงต้องใช้ได้เท่ากันทั้งกับผู้เข้าชมและเจ้าของเว็บไซต์

  • “ความทะเยอทะยาน” ของ Google ที่อยากเป็น gatekeeper แห่งอนาคตนั้นเกินไปแล้ว เพราะจริง ๆ Google ก็ทำหน้าที่ gatekeeper มาหลายปีผ่านส่วนแบ่งตลาดของ Chrome อยู่แล้ว Firefox เองก็แทบไม่มีตัวตน มุมมองนี้มองว่า Google กำลังชี้นำทั้งโลก www ไปในทิศทางที่ตัวเองต้องการ(แบน uBlock, บังคับใช้ฟอร์แมต .webp เป็นต้น)

• ก่อนจะชี้ว่า allowlist ที่บริษัทเดียวเป็นคนดูแลนั้นมีปัญหา ก็ควรยอมรับก่อนว่าจริง ๆ แล้วผู้ดูแลเว็บไซต์เป็นคนเลือกใช้บริการนั้นเอง สิ่งที่น่าสนใจคือความย้อนแย้งที่ในทางอุดมการณ์มีการถกเถียงเรื่อง “ความเป็นธรรม” แต่ในชีวิตจริงกลับโพสต์การ์ตูนที่ทำด้วยเครื่องมือ AI ลงบนบล็อก แสดงให้เห็นว่า AI แทรกซึมเข้ามาลึกแล้ว

  • Cloudflare กำลังนำมาตรฐาน Web Bot Auth ที่กำลังก่อตัวมาใช้งาน และพวกเรา Stytch ก็ใช้มาตรฐานเดียวกันที่ IsAgent.dev การถกเถียงตอนนี้ค่อนข้างร้อนแรงจึงอยากพูดอย่างระมัดระวัง แต่สุดท้าย allowlist ก็เป็นแค่ออปชันที่ Cloudflare มอบให้ลูกค้า และแกนหลักอย่าง HTTP Message Signature ถูกออกแบบให้เปิดและกระจายศูนย์ ใครก็ใช้ได้

  • การเลือกใช้ allowlist ของบริษัทหนึ่งด้วยความสมัครใจนั้นไม่ใช่ปัญหาใหญ่อะไร แต่เพียงเท่านั้นยังไม่ทำให้มันกลายเป็นโปรโตคอล และการถกเรื่องความเป็นธรรมกับการใช้การ์ตูน AI ก็ดูไม่มีความเชื่อมโยงทางตรรกะกัน

  • ในสถานการณ์แบบ frying pan/fire ที่ต้องเลือกระหว่างสิ่งไม่ดีสองอย่าง มีความเสี่ยงที่โซลูชันของบริษัทหนึ่งจะค้างอยู่ในฐานะมาตรฐานโดยพฤตินัย ทั้งที่ครั้งนี้อาจเป็นโอกาสสร้างโซลูชันบนโปรโตคอล/มาตรฐานจริง ๆ ได้ แต่ Cloudflare กลับพยายามสร้าง blue ocean ของตัวเอง และการอ้างเรื่อง “ความเป็นธรรม” ทั้งที่ในชีวิตจริงก็ใช้ AI อยู่ทั่วทุกมุม ก็เป็นการเหน็บแนมได้อย่างแสบสัน

• มองว่าคล้ายกับโครงสร้างของอีเมล อีเมลตั้งอยู่บนมาตรฐานอินเทอร์เน็ต แต่ผู้ใช้ส่วนใหญ่กลับอยู่กับผู้ให้บริการเพียงไม่กี่รายอย่าง Gmail Cloudflare เองก็ผลักดันมาตรฐานเปิดเช่นกัน แต่พลังที่แท้จริงมาจากจำนวนลูกค้าขนาดใหญ่ (พร้อมทั้งตั้งคำถามว่ามีทางแทนที่ที่ดีกว่านี้ไหม) และเหมือนกับที่อีเมลมีปัญหาเรื่องความน่าเชื่อถือในการส่งจากกระบวนการกรองสแปมและความซับซ้อนของการติดตั้ง เว็บก็อาจเดินไปในทิศทางเดียวกันได้

  • ในทางปฏิบัติแทบไม่มีทางเลือกมาทดแทน Cloudflare ในฐานะ CDN ฟรีได้เลย มันตั้งเซิร์ฟเวอร์ทั่วโลกและแจกใช้ฟรี แล้วไปหารายได้จากบริการ serverless ระดับพรีเมียม ขณะที่ผู้ให้บริการคลาวด์รายใหญ่ก็คิดค่า egress ของทราฟฟิกแพงผิดปกติ

• เว็บไม่ต้องการ attestation, signed agent หรือ Cloudflare มาตัดสินว่าใครคือเอเจนต์ “ของจริง” ทุกคนควรตระหนักความหมายของคำว่า “public” กันใหม่ และถ้าการรับมือทราฟฟิกเป็นเรื่องยาก ก็ทำแค่ rate limiting พื้นฐานก็พอ เว็บไม่จำเป็นต้องสนว่าผู้ขอเป็นมนุษย์ บอต หรือสุนัข แค่ส่งไบต์ให้ทุกคนภายใต้ทรัพยากรที่เหมาะสมก็พอ ถ้าแก่นของ “เว็บเปิด” แบบนี้หายไป ทุกคนคงเสียดาย

  • rate limiting ขั้นพื้นฐานเองก็อ่อนแอต่อการโจมตี จะมองข้าม botnet ก็ไม่ได้ และเมื่อย้ายไปสู่ IPv6 แล้ว rate limiting ที่ใช้ได้จริงก็แทบเป็นไปไม่ได้ ถ้ากำหนด bucket พลาด ผู้ให้บริการเครือข่ายบางรายแจกช่วง /48 ง่ายเกินไปจน limit ไร้ผล หรือผู้ใช้มือถือหลายแสนคนอาจถูกมัดรวมอยู่ใน rate limit เดียว

  • วิธีแบบนี้สุดท้ายก็ไม่ต่างอะไรจากการบอกให้เว็บไซต์เล็ก ๆ จำนวนมากปิดตัวเพราะรับทราฟฟิกไม่ไหว ซึ่งขัดกับสโลแกน “อินเทอร์เน็ตแบบเปิด”

  • AI crawler รุ่นใหม่ ๆ แยกจาก botnet อันตรายไม่ได้แล้ว rate limiting แบบปกติไม่มีความหมายอีกต่อไป และนี่แหละคือเหตุผลที่ Cloudflare เข้ามาพยายามแก้ปัญหา

  • คำกล่าวว่า “public ก็คือ PUBLIC” จะดีถ้ารันระบบได้ด้วย rate limiting พื้นฐาน แต่ในโลกจริงจำเป็นต้องระบุและเปิดเผยอัตราการเข้าถึงที่ยอมรับได้ ทว่าในหลายกรณีกลับถูกบล็อกเพียงเพราะ user-agent ต่างออกไป แม้จะร้องขอแค่ครั้งเดียว สุดท้ายผู้ดูแลระบบจึงมีแนวโน้มบล็อกทุกคำขอจากการดูที่ตัวตน(identity) มากกว่าพฤติกรรมของบอต เกณฑ์ตัดสินหยาบเกินไปจนเกิด false positive จำนวนมาก และถึงอย่างนั้นก็ไม่ตรวจดูความพยายามหรือบริบทใด ๆ เลย แค่เห็นตัวตนก็สั่งบล็อกทันที

  • rate limiting ขั้นพื้นฐานเองก็มักทำได้ไม่ง่ายนัก และถ้าไม่ใช่กรณีที่ต้องมีการยืนยันตัวตน/มอบอำนาจแบบเฉพาะ ก็คิดว่าการเข้าถึงไฟล์สาธารณะไม่จำเป็นต้องมี authentication หรือ delegation เพิ่มเติม ต่อให้มีประเด็น delegation จริง ๆ ก็ไม่จำเป็นต้องให้บุคคลที่สามอย่าง Cloudflare เข้ามาเกี่ยวข้องนอกเหนือจากบทบาทของผู้มอบอำนาจตัวจริง

• เห็นด้วยกับผู้เขียนเป็นส่วนใหญ่ ในสภาพแวดล้อมระดับองค์กรกำลังกังวลว่าจะควบคุมพฤติกรรมของ agent บนเครือข่ายภายในที่ซับซ้อนอย่างไร ช่วงหลังได้ลองสร้างระบบ “identity token” บนพื้นฐาน biscuit ด้วยตัวเอง โทเคนนี้ใช้ยืนยันตัวเอง แล้วจากนั้นก็สามารถสร้าง delegation token ส่งต่อให้ agent ลูกได้ ในระบบของฉัน ถ้าไม่มี authorization token ก็ทำอะไรไม่ได้เลย(แนวคิด single scope, single use) ถ้าเป็นบนอินเทอร์เน็ต ก็จินตนาการได้ว่าอาจแลก identity token + ไมโครเพย์เมนต์(เช่น ธุรกรรมคริปโตมูลค่าเล็กมาก) เพื่อรับ authorization token แบบนั้นมนุษย์แทบไม่ต้องเสียค่าใช้จ่ายอะไร แต่ AI crawler จะเป็นฝ่ายต้องจ่ายมาก