โครงสร้างพื้นฐาน FOSS กำลังถูกโจมตีจากบริษัท AI

 (thelibre.news)
1 คะแนน โดย GN⁺ 2025-03-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงสร้างพื้นฐาน FOSS หลายแห่ง เช่น SourceHut, KDE GitLab, GNOME GitLab, LWN, Fedora, Inkscape, Diaspora และ Read the Docs กำลังประสบปัญหาการล่ม การบล็อก และภาระในการดูแลระบบจาก AI crawler และรายงานความปลอดภัยที่สร้างด้วย AI
  • crawler เหล่านี้เพิกเฉยต่อ robots.txt หรือส่งคำขอซ้ำ ๆ ไปยัง endpoint ที่มีต้นทุนสูง อย่าง git blame, Git log และหน้าคอมมิต พร้อมใช้ IP หลายหมื่นรายการและ User-Agent ปลอมเพื่อปะปนกับทราฟฟิกผู้ใช้ทั่วไป
  • GNOME ได้นำ Anubis proof-of-work มาใช้ แต่ในช่วงเวลาราว 2 ชั่วโมง 30 นาที มีเพียง 3% จาก 81,000 คำขอที่ผ่านได้ ซึ่งชี้ว่าทราฟฟิกส่วนใหญ่น่าจะเป็นบอต
  • มีการตอบโต้หลายแบบต่อเนื่อง เช่น บล็อกบางเวอร์ชันของ Edge, จำกัดผู้ใช้ที่ไม่ได้ล็อกอิน, บล็อก subnet หรือทั้งประเทศ, รายการบล็อก IP, รวมถึง robots.txt และ .htaccess สำหรับ AI crawler ซึ่งทำให้ผู้ใช้จริงเจอความล่าช้าหรือถูกบล็อกด้วย
  • โครงการโอเพนซอร์สที่พึ่งพาความร่วมมือแบบสาธารณะมีพื้นผิวการเปิดเผยมากกว่าบริการปิด จึงได้รับผลกระทบจาก AI scraping และรายงานความปลอดภัยหลอนของ LLM ที่กัดกินเวลาและกำลังในการดูแลรักษาโดยตรง

เหตุขัดข้องที่เกิดซ้ำในโครงสร้างพื้นฐาน FOSS หลายแห่ง

  • Drew DeVault ผู้ก่อตั้งและ CEO ของ SourceHut วิจารณ์ว่าบริษัท LLM ต่าง ๆ ครอว์ลข้อมูลโดยไม่เคารพ robots.txt และทำให้ SourceHut เกิดปัญหาขัดข้องรุนแรง
  • โครงสร้างพื้นฐาน KDE GitLab ถูกใช้งานหนักเกินจาก AI crawler ที่มาจากช่วง IP ของ Alibaba จนทำให้นักพัฒนา KDE เข้า GitLab ไม่ได้ชั่วคราว
  • GNOME GitLab เริ่มแสดงหน้าจอโหลดเริ่มต้นของตัวท้าทาย proof-of-work Anubis เพื่อสกัด AI scraper ที่ทำให้เกิดปัญหาขัดข้อง
  • เมื่อกรณีสะสมมากขึ้น ความก้าวร้าวของ AI scraper ก็เพิ่มขึ้น และภาระการดูแลระบบของชุมชน FOSS ที่ตั้งอยู่บนความร่วมมือแบบเปิดก็สูงขึ้นตาม

วิธีทำงานของ crawler และความยากในการบล็อก

  • ตามคำบอกของ Drew DeVault, LLM crawler ไม่ทำตามข้อกำหนดใน robots.txt และไล่เก็บทั้งรีโพซิทอรีไปจนถึงหน้าที่มีต้นทุนสูง
    • เป้าหมายรวมถึง git blame, ทุกหน้าของ Git log และทุกคอมมิตในรีโพซิทอรี
    • crawler ใช้ User-Agent แบบสุ่มจาก IP หลายหมื่นรายการ และแต่ละ IP ส่งคำขอ HTTP ไม่เกินหนึ่งรายการเพื่อปะปนกับทราฟฟิกผู้ใช้
  • วิธีนี้ทำให้สร้างมาตรการบรรเทาได้ยาก และใน SourceHut งานลำดับความสำคัญสูงต้องล่าช้าออกไปเป็นสัปดาห์หรือเป็นเดือน
  • การแยกบอตกับคนจริงทำได้ยาก ทำให้ผู้ใช้จริงได้รับผลกระทบเป็นช่วง ๆ และนำไปสู่ปัญหาขัดข้องของ SourceHut
  • Drew ไม่ได้แยกว่าบริษัท AI ทุกแห่งปฏิบัติต่อ robots.txt หรือการรายงาน User-Agent แบบเดียวกันหรือไม่

การรับมือของ KDE และ GNOME

  • Ben จากทีม sysadmin ของ KDE ระบุว่า IP ที่ทำให้ KDE GitLab เกิด DDoS ทั้งหมดอ้างตัวว่าเป็น MS Edge และมีสาเหตุมาจากบริษัท AI ของจีน
    • Ben มองว่าผู้ให้บริการ LLM ฝั่งตะวันตกอย่าง OpenAI และ Anthropic อย่างน้อยก็ยังตั้งค่า User-Agent ให้ถูกต้อง
    • วิธีแก้ชั่วคราวคือบล็อกเวอร์ชัน Edge ที่บอตเหล่านั้นอ้างว่าใช้
    • แต่บอตมีแนวโน้มจะเปลี่ยน User-Agent เพื่อปะปน จึงใช้เป็นทางออกถาวรได้ยาก
  • GNOME เริ่มมีปัญหาตั้งแต่เดือนพฤศจิกายนปีที่แล้ว และได้ใช้ rate limit กับผู้ใช้ที่ไม่ได้ล็อกอินเพื่อไม่ให้ดู merge request และคอมมิตได้
    • มาตรการนี้ทำให้ผู้ใช้จริงที่ไม่ได้ล็อกอินมีปัญหาด้วย
  • หลังจากนั้น GNOME ก็เปลี่ยนไปใช้ Anubis
    • Anubis จะให้โจทย์คำนวณกับเบราว์เซอร์ และเมื่อเบราว์เซอร์ใช้เวลาแก้แล้วส่งคำตอบกลับเซิร์ฟเวอร์ จึงจะอนุญาตให้เข้าถึงได้
    • นักพัฒนาระบุว่านี่เป็น “มาตรการที่ใกล้เคียงกับทางเลือกแบบนิวเคลียร์” และเป็นสิ่งที่จำเป็นเพราะ AI scraper bot ไม่ทำตามมาตรฐานอย่าง robots.txt
  • Anubis ก็ยังส่งผลต่อผู้ใช้
    • หากมีคนจำนวนมากในสถานที่เดียวกันเปิดลิงก์ อาจได้รับโจทย์ที่ยากขึ้น
    • ผู้ใช้คนหนึ่งเจอความล่าช้า 1 นาที ขณะที่อีกคนต้องรอบนมือถือราว 2 นาที
    • เหตุการณ์แบบนี้เกิดขึ้นเมื่อมีการแปะลิงก์ GitLab ในห้องแชต หรือเมื่อ merge request เรื่อง Triple Buffering ของ GNOME ถูกโพสต์บน Hacker News จนได้รับความสนใจ
  • ตามตัวเลขที่ Bart Piotrowski ซึ่งเป็น sysadmin ของ GNOME แชร์ไว้ ในช่วงเวลาราว 2 ชั่วโมง 30 นาที จากทั้งหมด 81,000 คำขอ มีเพียง 3% ที่ผ่าน Anubis proof-of-work
    • อัตราการผ่าน Anubis: {p:3}
    • นี่บ่งชี้ว่าทราฟฟิก 97% อาจเป็นบอต

กรณีการบล็อกของ LWN, Fedora และ Inkscape

  • Jonathan Corbet ผู้ดูแล LWN แจ้งผู้ใช้ว่าเว็บไซต์ “อาจช้าเป็นครั้งคราว” เพราะ DDoS จาก AI scraper bot
    • เขาระบุว่าทราฟฟิกที่ให้กับผู้อ่านมนุษย์จริง ๆ นั้นมีสัดส่วนเพียงเล็กน้อยของทั้งหมด
    • ช่วงหนึ่งบอตเข้ามาพร้อมกันจาก IP หลายร้อยรายการ ไม่ระบุตัวเองว่าเป็นบอต และไม่แม้แต่อ่าน robots.txt
  • Kevin Fenzi ซึ่งเป็น sysadmin ของโครงการ Fedora ก็เจอปัญหาจาก AI scraper เช่นกัน
    • หนึ่งเดือนก่อน เขาต้องรับมือเพื่อให้ pagure.io ยังทำงานอยู่ได้
    • หลังจากนั้นสถานการณ์แย่ลงจนต้องบล็อกหลาย subnet และผู้ใช้จริงก็ได้รับผลกระทบด้วย
    • ในสถานการณ์คับขัน เขาบล็อกทั้งบราซิล และเข้าใจว่าการบล็อกนี้ยังคงมีผลอยู่
  • Neal Gompa ชี้ว่าการบล็อกทั้งประเทศก็มีข้อจำกัด และโครงสร้างพื้นฐาน Fedora “ล่มเป็นประจำมาหลายสัปดาห์” เพราะ AI scraper
  • Inkscape ก็เจอปัญหาเดียวกันเมื่อสัปดาห์ที่แล้ว
    • Martin Owens มองว่านี่ไม่ใช่ DDoS ทั่วไปจากจีนแบบปีที่แล้ว แต่เป็นกรณีที่หลายบริษัทเพิกเฉยต่อการตั้งค่า spider และปลอมข้อมูลเบราว์เซอร์
    • เขาสร้าง Prodigius block list และบอกว่าถ้าคุณทำงานอยู่ในบริษัทยักษ์ใหญ่ที่ทำ AI คุณอาจเข้าเว็บไซต์ Inkscape ไม่ได้อีกต่อไป

รายการบล็อก IP และความพยายามรับมือร่วมกัน

  • BigGrizzly จาก Frama software ก็ถูก LLM crawler ที่ไม่ดีถล่มเช่นกัน และได้สร้างรายการบล็อก 460,000 IP ที่ใช้ User-Agent ปลอม
    • เขาระบุว่าสามารถแชร์รายการนี้ได้
  • โปรเจกต์ ai.robots.txt เป็นความพยายามที่ครอบคลุมกว่านั้นในการทำรายการสาธารณะของ web crawler ที่เกี่ยวข้องกับบริษัท AI
    • มี robots.txt ที่ใช้ Robots Exclusion Protocol
    • และมีไฟล์ .htaccess ที่จะส่งหน้าข้อผิดพลาดกลับไปเมื่อมีคำขอจาก AI crawler ในรายการ

ตัวเลขทราฟฟิกของ Diaspora และ Read the Docs

  • จากการวิเคราะห์โครงสร้างพื้นฐาน Diaspora โดย Dennis Schubert พบว่าส่วนใหญ่ของเว็บทราฟฟิกมาจากบอตของบริษัท AI
    • บอตที่ใช้ User-Agent ของ OpenAI คิดเป็น หนึ่งในสี่ ของเว็บทราฟฟิกทั้งหมด
    • Amazon คิดเป็น 15% และ Anthropic คิดเป็น 4.3%
    • รวมแล้วราว 70% ของคำขอทั้งหมดถูกนับว่ามาจากบริษัท AI
  • Schubert กล่าวว่า บอตเหล่านี้ไม่ได้ครอว์ลครั้งเดียวแล้วจากไป แต่จะกลับมาทุก 6 ชั่วโมง และไม่สนใจ robots.txt
    • ถ้าใส่ rate limit ก็จะสลับไปใช้ IP อื่น
    • ถ้าบล็อกด้วยสตริง User-Agent ก็จะเปลี่ยนไปใช้สตริงที่ไม่ใช่บอต
    • เขาอธิบายว่านี่คือ DDoS ต่อทั้งอินเทอร์เน็ต
  • Read the Docs ระบุในบทความ “AI crawlers need to be more respectful” ว่าเมื่อบล็อก AI crawler ทั้งหมดแล้ว ทราฟฟิกลดลง 75%
    • อัตราการลดลงของทราฟฟิก: {p:75}
    • ทราฟฟิกลดจาก 800GB ต่อวันเหลือ 200GB ต่อวัน
    • ทำให้ประหยัดค่าใช้จ่ายได้ราว 1,500 ดอลลาร์ต่อเดือน
    • ยังมีกรณีที่ crawler ดาวน์โหลดข้อมูลไปหลายสิบ TB ภายในไม่กี่วัน
    • เนื่องจากพวกมันใช้หลาย IP จึงยากที่จะบล็อกได้ทั้งหมด
  • ตามคำบอกของ Schubert crawler “ปกติ” อย่าง Google และ Bing รวมกันยังมีสัดส่วนไม่ถึง 1%

ภาระการดูแลรักษาที่เกิดจากรายงานความปลอดภัยที่สร้างด้วย AI

  • ปัญหาไม่ได้หยุดอยู่แค่ scraper แต่ลามไปถึง รายงานบั๊กที่สร้างด้วย AI ด้วย
  • Daniel Stenberg จากโครงการ Curl กล่าวถึงปัญหารายงานบั๊กที่สร้างโดย AI ในบทความ “The I in LLM stands for Intelligence”
    • Curl มีโครงการ bug bounty
    • ช่วงหลังมีรายงานบั๊กจำนวนมากที่สร้างด้วย AI และแม้ภายนอกจะดูน่าเชื่อถือ แต่ก็ทำให้นักพัฒนาต้องเสียเวลาตรวจสอบ
    • อย่างไรก็ตาม รายงานเหล่านั้นมีอาการหลอนแบบที่คาดได้จาก AI ปะปนอยู่
  • Seth Larson ซึ่งอยู่ในทีม triage ของรายงานความปลอดภัยสำหรับ CPython, pip, urllib3 และ Requests ก็เจอปัญหาคล้ายกัน
    • โครงการโอเพนซอร์สได้รับรายงานความปลอดภัยแบบ LLM hallucination ที่คุณภาพต่ำมากและเป็นสแปมเพิ่มขึ้น
    • รายงานเหล่านี้เมื่อมองครั้งแรกอาจดูเหมือนถูกต้อง จึงต้องใช้เวลาในการโต้แย้ง
  • การรับมือรายงานความปลอดภัยมีต้นทุนสูงอยู่แล้ว และการต้องตอบสนองต่อรายงานบั๊กปลอมที่ดูน่าเชื่อถือยิ่งเพิ่มภาระให้ผู้ดูแลรักษาอย่างมาก
  • Larson ขอให้หลีกเลี่ยงการใช้ AI หรือระบบ LLM ในการตรวจหาช่องโหว่
    • เขาระบุว่าระบบปัจจุบันยังไม่สามารถเข้าใจโค้ดได้ และการตรวจหาช่องโหว่ต้องอาศัยความเข้าใจโค้ด รวมถึงเจตนา รูปแบบการใช้งานทั่วไป และบริบทในระดับที่ใกล้กับมนุษย์

ภาระเชิงโครงสร้างที่กระทบ FOSS มากกว่า

  • โครงการ FOSS มักมีทรัพยากรน้อยกว่าผลิตภัณฑ์เชิงพาณิชย์
  • โครงการที่ขับเคลื่อนโดยชุมชนมีส่วนของโครงสร้างพื้นฐานที่เปิดสาธารณะมากกว่า จึงเปิดรับ crawler มากกว่า
  • เพราะต้องมี issue สาธารณะ รายงานความปลอดภัย และโครงสร้างพื้นฐานเพื่อการทำงานร่วมกัน ทำให้ AI scraper และ issue ที่สร้างด้วย AI กลายเป็นภาระพร้อมกัน
  • สุดท้ายแล้ว การรับมือเหตุขัดข้อง นโยบายการบล็อก การลดผลกระทบต่อผู้ใช้ และการตรวจรายงานความปลอดภัยปลอม ต่างก็กินเวลาของผู้ดูแลโอเพนซอร์ส

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

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

 
GN⁺ 2025-03-21
ความคิดเห็นบน Hacker News

  • มีกรณีนี้ด้วย: https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse... เป็นบทความที่ถูกอ้างถึงในต้นฉบับด้วย และคนรู้จักที่ดูแลโครงสร้างพื้นฐานอินเทอร์เน็ตขนาดใหญ่ต่างก็เจอเรื่องคล้าย ๆ กัน
    บทความนี้รวบรวมกรณีแบบนั้นไว้ในที่เดียวได้ดี อย่างที่บอกตอนเขียนบทความ พวกเขากำลังเผา ทุนความน่าเชื่อถือ จนหมดเกลี้ยง
    สตาร์ทอัพรายสำคัญรายหนึ่งในวงการนี้ร่วมมือกับเราโดยตรง คืนเงินค่าใช้จ่ายให้ และแก้บั๊กของครอว์เลอร์แล้ว ในทางกลับกัน Facebook ไม่ตอบอีเมล และลิงก์ใน User Agent ก็เป็น 404 วิศวกรของบริษัทเห็นบทความแล้วบอกอีเมลที่ถูกต้องให้ แต่ส่งไปที่นั่น 3 ครั้งก็ยังไม่มีคำตอบ

    • บริษัท AI ดูเหมือนจะทำตัวราวกับทุนความน่าเชื่อถือไม่สำคัญ ทำตามใจเหมือนกอริลลา 800 ปอนด์ที่มี เงินทุน 100 พันล้านดอลลาร์
      ท่าทีคือ ไม่ว่าคุณจะต้องการหรือไม่ AI จะเข้าไปอยู่ในทุกผลิตภัณฑ์ และไม่ว่าคุณจะต้องการหรือไม่ มันจะดูดข้อมูลทั้งหมดไป
    • ตรงที่ว่า “ครอว์เลอร์ตัวหนึ่งดาวน์โหลดไฟล์ HTML ที่บีบอัดแล้ว 73TB ในเดือนพฤษภาคม 2024 ทำให้มีค่าแบนด์วิดท์เกิน 5,000 ดอลลาร์” ทำให้ต้องกลับมาอ่านซ้ำ
      ผมดูแลโครงสร้างพื้นฐานที่รับทราฟฟิกหลายร้อย TB ต่อเดือน โดยเน้นเซิร์ฟเวอร์เฉพาะเป็นหลัก ต้นทุนทราฟฟิกอยู่ราว ๆ 0.50~3 ดอลลาร์ต่อ TB แม้จะแตกต่างกันตามภูมิภาค แต่ ค่า egress traffic ของ AWS นี่บ้าบอจริง ๆ
    • ถ้าไม่ตอบ ก็ส่งใบแจ้งหนี้ไปที่ ทีมบัญชีเจ้าหนี้ แทนอีเมลได้เลย
    • ถ้าส่งอีเมลไป 3 ครั้งแล้วยังไม่ตอบ ตั้งแต่นั้นควรมองว่าการครอว์ลไม่ใช่บั๊กหรือความผิดพลาด แต่เป็น DDoS แล้วหรือเปล่า?
    • แล้วถ้าป้อนข้อมูลขยะที่สร้างแบบไดนามิกให้มันไปเลยล่ะ? น่าจะสนุกกว่าการไม่ให้อะไรเลย

  • เห็นโปรเจกต์ของผมโผล่มาเป็นภาพพรีวิวแบบนี้แล้วรู้สึกเหนือจริงมาก สุดยอดเลย! ถ้าอยากลองใช้ อยู่ที่นี่: https://github.com/TecharoHQ/anubis
    เท่าที่ดูมาจนถึงตอนนี้ มันดูเหมือนจะใช้งานได้จริง ผมนำไป deploy ไว้ที่ xeiaso.net เพื่อดูว่ามันจะล้มเหลวอย่างไรในสภาพแวดล้อมจริงบนบล็อกของผม

    • น่าจะใส่คำอธิบายให้ผู้ใช้สักหน่อยว่าตอนนี้ต้องทำอะไร และกำลังเกิดอะไรขึ้นบนหน้านั้น
      แม้จะมีวิดเจ็ตแอนิเมชันโหลดอยู่ แต่ตอนที่เห็นครั้งแรกใน issue tracker ของ Gnome เมื่อไม่กี่สัปดาห์ก่อน proof of work ใช้เวลาประมาณ 20 วินาที และผมไม่รู้ว่าเกิดอะไรขึ้น ตอนแรกคิดว่าถูกบล็อกหรือแคปชาไม่โหลด
      ตอนนี้รู้แล้วว่ามันคืออะไร แต่ถ้าดูหน้า “กำลังตรวจสอบว่าคุณเป็นบอตหรือไม่” แบบเดี่ยว ๆ ก็ยังไม่ได้ชัดเจน 100%
    • ผมชอบวิธีนี้มาก อินเทอร์เน็ตจะทำตัวเหมือนยุคบุกเบิกตะวันตกก็พอรับได้ แต่ไม่ชอบที่ไม่มี ความรับผิดชอบ
      เป็นวิธีที่ดีสำหรับฝั่งที่อยากเปิดเว็บไซต์ให้ใช้ฟรีต่อไป โดยผลักภาระทางเศรษฐกิจไปให้ครอว์เลอร์ ถ้าอยากได้ข้อมูล ฝั่งที่มาเอาก็ควรเป็นคนจ่าย
      ข้อเสียคืออาจหลุดจากเสิร์ชเอนจิน แต่ก็ไม่มีเหตุผลอะไรที่ลงทะเบียนบริการไว้กับดัชนีระดับโลกหรือดัชนีแบบ P2P ไม่ได้
    • ชอบนะ ทำออกมาดีเช่นเคย
      และเกี่ยวกับ https://news.ycombinator.com/item?id=43422781 ถ้าเพิ่มวิธีคำนวณเงินจำนวนจิ๋วของ shitcoin ที่ต้องการเข้าไป ก็อาจกลายเป็น กรณีใช้งานคริปโตที่มีประโยชน์จริง อีกอย่างหนึ่งก็ได้
    • Anubis จะใช้ได้ก็ต่อเมื่อยังไม่ดัง พอดังขึ้นมา ครอว์เลอร์ก็จะเริ่มใช้ GPU/ASIC จัดการ proof of work แล้วก็จบกัน
    • ชอบที่บางครั้งก็ได้บังเอิญเจอสิ่งที่คุณทำขึ้นมา ผมชอบรูปแบบการอธิบายแบบบล็อกด้วย เลยคิดว่าจะไปดู Anubis เพิ่มเติม

  • ถ้าดูจากความเร็วนี้ ปัญหาไม่ได้จำกัดอยู่แค่โครงสร้างพื้นฐานเสรี/โอเพนซอร์สเท่านั้น แน่นอนว่านั่นเป็นเหมือนนกคานารีในเหมืองถ่านหิน จึงยิ่งรู้สึกร่วมเป็นพิเศษ แต่ท้ายที่สุดแล้วนี่คือปัญหาของ การเข้าถึงอินเทอร์เน็ตแบบนิรนาม ทั้งหมด
    คุณอาจเอาไซต์ไปไว้หลังกำแพงยืนยันตัวตนได้ แต่บอตรุ่นใหม่ต่างจากเมื่อก่อนตรงที่มันแก้ CAPTCHA ได้และเลียนแบบผู้ใช้จริง โดยเฉพาะเมื่อใช้ IP ที่พักอาศัยกับ User Agent ปลอม หรือแม้แต่ User Agent จริงที่เชื่อมกับเครื่องมืออย่าง Playwright ตามที่บทความกล่าวไว้
    สุดท้ายแล้วจะเหลืออะไร นอกจากไซต์ต่าง ๆ เริ่มเรียกบัตรเครดิต, Worldcoin หรือทางเลือกอื่นที่น่าหดหู่พอ ๆ กัน

    • เรามาถึงครึ่งทางแล้วด้วยซ้ำ ผมรู้สึกได้ทุกครั้งที่ทำแมป OpenStreetMap แล้วต้องค้นหาธุรกิจท้องถิ่นที่ไม่มีเว็บไซต์ของตัวเอง
      พวกเขาใช้ Facebook, Instagram, X ฯลฯ เหมือนนามบัตรดิจิทัล ผมปกติไม่ได้ใช้ Facebook หรือ Instagram เลิกใช้ X ไปแล้ว และไม่มีบัญชี พอตามลิงก์พวกนั้นไป ก็เห็นข้อมูลได้แค่บางส่วน แล้วมีไดอะล็อกเด้งขึ้นมาบอกให้สร้างบัญชีหรือออกไป ไม่ก็เจอข้อผิดพลาดที่ไม่รู้สาเหตุ
      การเข้าร่วมคอมมูนิตี้ส่วนตัวนั้นไม่เป็นไร แต่การมีอุปสรรคแบบนี้กับข้อมูลที่คนโพสต์โดยคิดว่าน่าจะมองเห็นได้สาธารณะ มันน่าหงุดหงิดจริง ๆ
    • ถ้าพูดส่วนที่มักพูดกันเบา ๆ ให้ดังขึ้น หนึ่งในเหตุผลใหญ่ที่เรื่องนี้น่าหดหู่คือมันไม่ใช่แค่การทำลายธรรมดา แต่เป็นการทำลายที่ทำให้เหล่าตัวร้ายที่เกี่ยวข้องได้ ผลประโยชน์ทบต้น การดูดคอนเทนต์ไปเป็นแค่จุดเริ่มต้น
      ต้นทุนเพิ่มจนไซต์ต้องปิดถาวร? เยี่ยมเลย เพราะผู้คนต้องใช้ AI กับเอกสารทุกอย่าง บีบให้ถอยจาก CAPTCHA ไปใส่บัตรเครดิตหรือเบอร์โทร? เยี่ยมเลย เพราะความนิรนามบนอินเทอร์เน็ตลดลงไปอีก
      ข้อมูลรั่วไหลทำให้การฉ้อโกงเพิ่มขึ้น? เยี่ยมเลย เพราะคงต้องใช้ AI มาป้องกัน สำหรับผู้ประสงค์ร้ายแล้ว แทบทุกทางคือเกมที่ตัวเองชนะ
      การแบ่งแยกอินเทอร์เน็ตเป็นค่าย ๆ ถูกพูดถึงมานานแล้ว ภัยคุกคามเหล่านั้น หรือข้อเท็จจริงที่ว่ามันเป็นกองขยะที่ควบคุมไม่ได้อยู่แล้ว น่าจะทำให้คนระมัดระวังขึ้นบ้างในการทำให้สถานการณ์แย่ลง แต่การผลักขีดจำกัดว่าผู้คนทนการรบกวนและแรงเสียดทานได้แค่ไหนนั้นสุดท้ายก็ไม่สำคัญอยู่ดี เพราะไม่มีทางเลือกจริง ๆ
    • ผมก็ไม่แน่ใจ ผมเปิดเกมเบราว์เซอร์เล็ก ๆ อยู่ เซิร์ฟเวอร์โดนสแครปเปอร์ LLM ถล่มเป็นระยะจนเละไปหมด แต่ยังไม่เคยเห็นบัญชีใหม่ที่ดูเหมือนบอตสร้างเลยสักบัญชี
      อัตราสมัครใหม่ก็ไม่ได้เปลี่ยนอย่างเห็นได้ชัด ทั้งในเกมและวิกิ และทราฟฟิกสแครปส่วนใหญ่ก็ไปลงที่วิกิ ถ้าการสแครปไม่ลดลง วิกิคงมีแนวโน้มสูงที่จะต้องถูกย้ายไปอยู่หลังกำแพง ยืนยันตัวตน แทบทั้งหมด
    • อาจเป็นแนวทางประมาณว่า หากต้องการส่งคำขอ X รายการถัดไป ต้องประมวลผลโทเค็นจำนวนเท่านี้ แน่นอนว่าฟังดูยูโทเปียพอสมควร
    • ไม่จำเป็นต้องอยู่หลังกำแพงยืนยันตัวตนเสมอไป การใช้ บริการไมโครเพย์เมนต์แบบนิรนาม ต่อคำขอแต่ละครั้งก็เป็นไปได้เต็มที่
      ถ้าอินเทอร์เน็ตเป็นแบบที่การมีผู้เยี่ยมชมมากเกินไปกลายเป็นวิกฤตต่อการดำรงอยู่ของเว็บไซต์ ก็แปลว่าอินเทอร์เน็ตที่เราใช้อยู่ไม่ได้ถูกออกแบบมาให้มีชีวิตรอดได้นาน

  • เมื่อก่อนตอนเสิร์ชเอนจินก่อปัญหาแบบนี้ อุตสาหกรรมตกลงกันเพื่อหลีกเลี่ยงการเกิดกฎระเบียบทางกฎหมาย และสร้างสเปก robots.txt ขึ้นมา ดังนั้นจึงไม่มีกรอบกฎหมายเกิดขึ้น
    ตอนนี้มีอินเด็กเซอร์รุ่นใหม่ที่หิวกระหายซึ่งไม่ได้เข้าร่วมข้อตกลงนั้น และด้วยแรงกดดันจากการแข่งขัน พวกเขาพยายามกวาดข้อมูลให้ได้มากที่สุดเท่าที่ทำได้ และเมิน robots.txt ไปเลย
    ไม่ว่าอย่างไร ก็ควรมีการออกกฎหมายตั้งแต่แรก และฝ่ายที่เพิกเฉยต่อ robots.txt ควรถูกบล็อก ปรับ จำกัดความเร็ว ฯลฯ

    • ผมไม่แน่ใจว่าชอบแผนนี้ไหม เราไม่ควรปล่อยให้ AI ผิดกฎหมายมีความรู้และประโยชน์ใช้สอยมากกว่า AI ถูกกฎหมาย
      ยังมีทางเลือกอื่นนอกเหนือจากการแบนทั้งหมด
    • ผมคงแปลกใจมากถ้ามีสมาชิกสภาผู้แทนราษฎรหรือสมาชิกรัฐสภาสหรัฐฯ สักคนที่รู้ว่า robots.txt คืออะไร
    • กฎหมายของสหรัฐฯ หรือ EU จะหยุดทราฟฟิกจากจีน ไทย รัสเซียได้อย่างไร? อย่างมากก็ทำให้อินเทอร์เน็ตแตกเป็นเสี่ยง ๆ ซึ่งไม่ใช่ “ทางที่ดีที่สุด” และเป็นไอเดียที่แย่มาก

  • ผมเองก็เพิ่งโดนโจมตีเมื่อไม่นานนี้ [0] มันเป็นอินสแตนซ์ Forgejo เล็ก ๆ ที่ใช้เผยแพร่โค้ดแพ็กเกจโอเพนซอร์สหลายตัว จึงต้องเปิดเป็นสาธารณะ แต่สุดท้ายพังยับ และดิสก์เต็มเพราะไฟล์ ZIP archive ที่ถูกสร้างขึ้น
    ไม่ใช่ผมคนเดียวที่เจอแบบนี้ ในกรณีของผม พอบล็อกช่วง IP ของ Alibaba Cloud การโจมตีก็เบาลงไปก่อน
    ถ้าคุณรันอินสแตนซ์ Forgejo ผมขอแนะนำอย่างยิ่งให้ตั้งค่า DISABLE_DOWNLOAD_SOURCE_ARCHIVES เป็น true ตัวครอว์เลอร์อาจยังเกาะกิน CPU หนักอยู่ แต่至少ดิสก์จะไม่เต็มไปด้วยไฟล์ ZIP
    [0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

    • “ดิสก์เต็มเพราะไฟล์ ZIP archive ที่ถูกสร้างขึ้น” หมายความว่านี่คือ การออกแบบซอฟต์แวร์ที่แย่ ซึ่งสร้างไฟล์ ZIP แบบทันที
    • บางทีอาจดีกว่าถ้าเปลี่ยนไปใช้ซอฟต์แวร์ที่ทำมาดีและออกแบบอย่างเหมาะสมสำหรับให้บริการบนอินเทอร์เน็ตสาธารณะ
      การออกแบบที่สร้างไฟล์ ZIP เขียนลงดิสก์ทั้งก้อน แล้วค่อยส่งให้ไคลเอนต์ทีเดียว เป็นวิธีที่เลวร้ายสุด ๆ และใช้งานไม่ได้ การออกแบบที่ถูกต้องควรสร้างและส่งต่อให้ไคลเอนต์แบบค่อยเป็นค่อยไป โดยใช้หน่วยความจำน้อยที่สุดและไม่ใช้ดิสก์เลย
      การมีดีไซน์ไร้สาระแบบนี้เป็นสัญญาณว่านักพัฒนาแทบไม่สนใจประสิทธิภาพ และมีความเป็นไปได้สูงว่าจะมีปัญหาร้ายแรงคล้าย ๆ กันอีกเพียบ
      ตัวอย่างเช่น ถ้าดูซอร์สโค้ด Forgejo แบบคร่าว ๆ ดูเหมือนว่ามันจะสตาร์ตโปรเซส “git” แทนที่จะใช้ไลบรารีเฉพาะสำหรับงาน Git ทั้งหมด ผมยังไม่ได้ตรวจสอบยืนยัน แต่ก็คงไม่แปลกใจถ้างานเหล่านั้นห่างไกลมากจากวิธีที่มีประสิทธิภาพที่สุดในการทำปฏิบัติการนั้น ๆ
      ถ้ารันซอฟต์แวร์ที่ย่ำแย่สุดขีดแบบนี้ ก็ไม่น่าแปลกใจที่ CPU จะค้างอยู่ที่ 100% และเซิร์ฟเวอร์ใช้งานไม่ได้

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

    • ในความเป็นจริง น่าจะกลายเป็น เสถียรภาพแบบเลียปูนอฟ เหมือนประชากรหมาป่ากับกระต่าย ในสถานการณ์นี้พวกเราคือกระต่าย
      เมื่อประชากร AI ลดลง คอนเทนต์จากมนุษย์ก็เพิ่มขึ้น ซึ่งกลายเป็นอาหารให้ AI มากขึ้นจน AI กลับมาเพิ่มขึ้นอีก จากนั้นการแสดงออกของมนุษย์ก็ถูกกลบ และมนุษย์ก็เงียบลง เมื่ออาหารของ AI ลดลง AI ก็ลดลง เสียงรบกวนลดลง และมนุษย์ก็กลับมาเติบโตอีก วัฏจักรนี้จะวนซ้ำอย่างน่าเบื่อหน่าย
    • ส่วนตัวผมคิดว่านี่คือหนึ่งในแรงจูงใจจริง ๆ ของ Web Environment Integrity คือให้ Google ทำดัชนีได้ แต่ที่อื่นทำไม่ได้
      เรากำลังติดอยู่กับทางเลือกที่ลำบาก: อยากได้ผู้เล่นรายใหญ่เดิมที่ฝังรากแน่น หรืออยากได้โฮสติ้งราคาถูกและเปิดกว้าง?
    • Google กวาดข้อมูลไซต์ไปแล้วแสดงคำตอบตรงในผลการค้นหา ถ้าคุณให้ความสำคัญกับทราฟฟิกและอยากขายพื้นที่โฆษณา ตอนนี้ทำไมถึงควรอยากให้ Google ทำดัชนีไซต์ของคุณ?
      ไซต์ที่อิงโฆษณาจำนวนมากคงจะมืดดับไป เพราะผู้เยี่ยมชมจะมีแต่บ็อต
    • ถ้าต้องย้ายไปสู่การครอว์ลแบบอิงการยืนยันตัวตน สถานะของเสิร์ชเอนจินเดิมก็จะแข็งแกร่งขึ้นอีก เพราะมีแต่ครอว์เลอร์ที่ได้รับเชิญเท่านั้นที่จะเข้าถึงได้
      ถ้ามีเครื่องมือง่าย ๆ คนส่วนใหญ่ก็คงอนุญาตแค่ Google, Bing และอย่างมากอีกสักหนึ่งหรือสองราย
    • บริษัท AI ที่มี เทคนิคหลบเลี่ยงแคปช่า ดีที่สุดจะเป็นผู้ชนะ และจะแทรกโฆษณาลงในเอาต์พุตของ LLM ด้วยวิธีที่ซับซ้อนยิ่งขึ้น

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

    • เคยเห็นมีการใช้แนวทางแบบนี้ แต่ไม่แน่ใจว่าอัตราสำเร็จเป็นอย่างไร ในเชิงตรรกะก็ดูสมเหตุสมผล
      คืออ้างอิงเส้นทางที่มนุษย์จริง ๆ มองไม่เห็นอย่างชัดเจน แล้วถือว่าทราฟฟิกที่ยิงเข้าเส้นทางนั้นเป็นบ็อต พวกบ็อตอดใจไม่ไหวหรอก
    • ใช่ แต่ต้องเพิ่มไว้ใน robots.txt ด้วย เพื่อให้มีแต่โรบอตไม่ดีเท่านั้นที่โดนเล่นงาน
    • เมื่อวานอ่านเรื่องนี้แล้วลองคิดวิธีบรรเทาในสเกลที่ใหญ่ขึ้น เว็บไซต์สร้างพาธหรือเอนด์พอยต์เสมือนแบบสุ่ม แล้วพาบ็อตเข้าไปยัง Library of Babel[0] ที่ให้บริการในเครื่อง เพื่อปนเปื้อนสไปเดอร์ด้วยข้อความไร้ประโยชน์
      คงใช้ไม่ได้กับไซต์ที่มีโครงสร้างดีซึ่งบ็อตรู้เอนด์พอยต์ที่ต้องการกวาดข้อมูลอย่างแม่นยำ แต่ก็น่าจะช่วยชะลอเธรดสไปเดอร์ที่สำรวจแบบกว้าง ๆ ได้
      [0] https://libraryofbabel.info/
    • นอกจากการท่วมด้วยขยะแล้ว แล้ว การก่อกวนโดยตรง อย่างการเสิร์ฟอะไรแบบ ZIP bomb หรือทำให้มันเสียทรัพยากรคำนวณล่ะ?

  • นี่คือ VideoLAN
    พวกเราก็โดน บ็อตของบริษัท AI ถล่มฟอรัมและ Gitlab เหมือนกัน
    ส่วนใหญ่ไม่เคารพ robots.txt

    • ได้ทำเอกสารมาตรการที่ใช้แก้ปัญหานี้ไว้ไหม?

  • บ้ามาก สุดท้ายจะไปสู่เว็บเวอร์ชันที่เสิร์ชเอนจินไม่ทำดัชนีหรือเปล่านะ เป็นเว็บที่ใกล้เคียงกับการท่องเว็บยุค 90 มากขึ้น คือเว็บไซต์ต่าง ๆ ต้องลิงก์ถึงกันถึงจะถูกพบ
    ผมชอบที่ทางแก้สำหรับการสแครปโดย LLM คือให้เบราว์เซอร์ทำ proof of work ก่อนอนุญาตให้เข้าถึง สงสัยว่าไซต์ใหม่ ๆ จะเริ่มนำสิ่งนี้มาใช้ไหม
    แบบนั้นเสิร์ชเอนจินจะไม่ทำดัชนี แต่ก็ช่วยปกป้องทรัพย์สินทางปัญญาได้

    • สวัสดี! ผมกำลังทำสิ่งนั้นอยู่ ดูรายละเอียดได้ที่ https://github.com/TecharoHQ/anubis

  • ที่ผ่านมาไม่เคยคิดถึงเรื่องนี้ แต่บ้าจริง ๆ ที่บริษัทซึ่งให้บริการทั้งผลิตภัณฑ์ LLM และบริการคลาวด์คอมพิวติ้งได้ กำไรสองต่อ
    ได้ผลิตภัณฑ์ LLM ที่นำไปขายได้ และในขณะเดียวกันก็ได้ค่าใช้จ่ายทราฟฟิกขาออกกับค่าคอมพิวต์จากโหลดที่เพิ่มขึ้นด้วย มองแบบนี้แล้วจะมีแรงจูงใจอะไรให้สนใจการสแครปของ LLM ที่ไม่มีประสิทธิภาพ? ยิ่งปล่อยให้เละเทะ ก็ยิ่งได้เงินจากจักรวรรดิอีกฝั่งของตัวเอง คือค่าทราฟฟิกขาออกของคลาวด์สตอเรจ