AI scraper แบบก้าวร้าวกำลังทำให้การดูแลวิกิยากขึ้นมาก

 (weirdgloop.org)
5 คะแนน โดย GN⁺ 2 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทราฟฟิกจาก AI scraper กำลังสั่นคลอนทั้งต้นทุนและเสถียรภาพของวิกิสาธารณะ และหากไม่บรรเทาอย่างต่อเนื่อง อาจใช้ทรัพยากรคอมพิวต์มากกว่ากิจกรรมทั้งหมดของมนุษย์รวมกันราว 10 เท่า
  • บอตไม่ได้มีแค่ User Agent ที่ระบุตัวได้อย่าง GPTBot เท่านั้น แต่ยังปลอม header ให้ดูเหมือน Chrome รุ่นล่าสุด และอ้อมผ่านพร็อกซีที่อยู่อาศัยซึ่งหมุนเวียน IP วันละ 1 ล้านรายการ
  • วิกิเปิดเผย URL ของ revision เก่า หน้าจอแก้ไข และหน้าพิเศษ มากกว่าหน้าเอกสารธรรมดามาก ทำให้การ crawl แบบไร้เดียงสาข้ามแคชและอาจมีต้นทุนสูงกว่าคำขอปกติ 50–100 เท่า
  • Cloudflare Challenge, Anubis, กฎไฟร์วอลล์แบบทำมือ และการตรวจจับจาก คำขอที่สะท้อนพฤติกรรมมนุษย์ มีประสิทธิภาพ แต่ก็มาพร้อม false positive ภาระดูแลรักษา และแรงเสียดทานต่อผู้อ่าน
  • การบังคับล็อกอินหรือท้าทายทุกทราฟฟิกแบบสุดโต่งอาจลดผู้มีส่วนร่วมหน้าใหม่ จึงต้องมี การพูดคุยแบบเปิดเผย ระหว่างผู้ดูแลและแนวทางแบบ API ที่เปลี่ยนแรงจูงใจในการเก็บข้อมูลของบอต

ภาระที่ AI scraper สร้างให้กับการดูแลวิกิ

  • การ scrape โดยบอตเพื่อเก็บข้อมูลฝึก LLM เพิ่มขึ้นในระดับที่ไม่เคยมีมาก่อน จนสั่นคลอนทั้งต้นทุนและเสถียรภาพของเว็บไซต์สาธารณะ: ประเด็นนี้ถูกพูดถึงใน FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline?, และ Smart TV web crawler AI
  • Weird Gloop โฮสต์วิกิเกมขนาดใหญ่อย่าง Minecraft Wiki, OSRS Wiki, League Wiki และในช่วง 3 ปีที่ผ่านมาใช้เวลากับการ รับมือทราฟฟิกบอต มากขึ้นเรื่อยๆ
  • หากไม่บรรเทาอย่างต่อเนื่อง บอตอาจใช้ ทรัพยากรคอมพิวต์ มากกว่าทุกอย่างที่เหลือรวมกันราว 10 เท่า ซึ่งรวมถึง pageview จากมนุษย์หลายสิบล้านครั้งและการแก้ไขหลายหมื่นครั้งต่อวัน
  • Wikimedia Foundation ก็เผยแพร่บทความว่าด้วยผลกระทบของ crawler ต่อการดำเนินงาน และวิกิฟาร์มหลักหลายแห่งประสบปัญหาขัดข้องในระดับต่างๆ ขณะที่วิกิอิสระขนาดเล็กบางแห่งออฟไลน์ไปเลย
  • คาดว่าปัญหาเซิร์ฟเวอร์ในระบบนิเวศวิกิปีนี้ราว 95% มีสาเหตุมาจาก scraper ที่ไม่พึงประสงค์

scraper ที่พยายามทำตัวให้เหมือนคน

  • บอต “ทางการ” ของบริษัท AI รายใหญ่อย่าง GPTBot, ClaudeBot และ PerplexityBot เคยมีกรณีไม่ทำตาม robots.txt แต่ปกติยังพอระบุได้จากสตริง User Agent จึงบล็อกได้ค่อนข้างง่ายด้วย Cloudflare การบล็อก AI bots หรือ nginx
  • เมื่อเว็บมาสเตอร์เริ่มบล็อก AI scraper ตาม User Agent บอตจึงมีแรงจูงใจสูงที่จะ ปลอมตัวเป็นทราฟฟิกมนุษย์
  • ปัจจุบันทราฟฟิก AI scraper ส่วนใหญ่ที่เข้าถึงวิกิจะส่ง header และจัดรูปแบบคำขออย่างพิถีพิถันให้ดูเหมือน Google Chrome เวอร์ชันล่าสุด
  • สัญญาณชัดๆ แบบเดิมที่ใช้แยกว่า “นี่คือบอตหรือคนจริง” จึงหายไป ทำให้บล็อกได้ยากขึ้น

IP หลายสิบล้านและการอ้อมผ่านพร็อกซี

  • ก่อนปี 2023 การ scrape ที่เป็นปัญหาราว 95% มาจาก IP เดี่ยวหรือ subnet ของดาต้าเซ็นเตอร์ขนาดเล็ก ทำให้การบล็อกตาม IP หรือคุณลักษณะของ ISP ยังได้ผลค่อนข้างดี
  • เมื่อใช้พร็อกซีที่อยู่อาศัย ก็สามารถฟอกคำขอ scrape ผ่านเครือข่าย IP หลายล้านรายการได้ด้วยแค่บัตรเครดิต
  • บางครั้งวิกิต้องเจอกับ scraper ที่หมุนเวียน IP 1 ล้านรายการต่อวัน และดูเหมือนเป็นคำขอปกติจาก ISP ที่อยู่อาศัยอย่าง Comcast, AT&T และ Charter
  • ลูกค้าเหล่านั้นมีแนวโน้มจะไม่รู้เลยว่า IP ของตนถูกใช้เป็น exit node ของพร็อกซีที่อยู่อาศัย
  • ผู้ไม่หวังดีบางรายใช้facebookexternalhit preview ลิงก์ หรือ Google Translate เพื่อให้คำขอดูเหมือนมาจากเซิร์ฟเวอร์ Google/Facebook และซ่อนแหล่งที่มาจริง
  • มีกรณีที่คำขอ 99.99% ที่เข้ามาผ่านเครื่องมือ URL ของ Google Translate เป็นการใช้งานในทางที่ผิด จนครั้งหนึ่งต้องทำให้เครื่องมือนี้ใช้ไม่ได้กับทุกวิกิ

การ crawl “URL งี่เง่า” ที่แพงเป็นพิเศษสำหรับวิกิ

  • AI scraper จำนวนมากเลือก URL โดยเข้าหน้าแรกของวิกิ จากนั้นไปทุกลิงก์บนหน้านั้น แล้วไปทุกลิงก์ของหน้าถัดๆ ไปอีกที
  • ทั้งที่ robots.txt และ sitemap ก็บอกอยู่แล้วว่า URL ไหนคุ้มค่าต่อการ scrape แต่ดูเหมือนบอตจะไม่รับรู้
  • OSRS Wiki มีบทความอยู่ราว 40,000 หน้า และ URL เหล่านี้คือข้อมูลที่มีประโยชน์เกือบทั้งหมดของเว็บไซต์
  • แต่เมื่อรวม revision เก่า, หน้าจอแก้ไข, และ หน้าพิเศษ จำนวน URL ที่สามารถสำรวจได้จะพุ่งไปอย่างน้อย 1 พันล้านรายการ
  • การ crawl แบบไร้เดียงสานี้ไม่มีวันจบ และดูเหมือนสิ้นเปลืองทรัพยากรจำนวนมากกับ URL ที่ไม่มีประโยชน์ต่อข้อมูลฝึก LLM
  • คำขอประหลาดเหล่านี้ยังข้ามชั้นแคชอย่าง MediaWiki parser cache ที่คำขอของผู้ใช้จริงอาศัยอยู่ ทำให้ต้นทุนบริการสูงขึ้น
  • คำขอที่ cache hit มักใช้เวลาประมวลผล ต่ำกว่า 20 มิลลิวินาที แต่คำขออย่าง diff เก่าๆ มักใช้เวลา 1–2 วินาที
  • เมตริกระดับบนอย่าง “บอต 8 ล้านคำขอต่อวัน” หรือ “บอตใช้แบนด์วิดท์ 65%” ประเมินปัญหาต่ำเกินไป
  • คอขวดจริงมักอยู่ที่ความจุ CPU และคำขอบอตที่แนบ query parameter แปลกๆ มักมีต้นทุนประมวลผลสูงกว่าคำขอทั่วไป 50–100 เท่า

สไปก์ของทราฟฟิกที่ค่าเฉลี่ยบอกไม่ออก

  • คำขอบอตต่อเดือนอยู่ที่ราว 250 ล้านครั้ง หรือเฉลี่ยประมาณ 100 ครั้งต่อวินาที แต่ตัวเลขนี้เป็นเพียงค่าเฉลี่ยระยะยาว
  • scraper มักส่งคำขอเกิน 1,000 ครั้งต่อวินาที ในช่วงเวลาสั้นๆ และแทบแยกไม่ออกจากการโจมตี DDoS แบบดั้งเดิม
  • แม้ในระยะยาวบอตจะกิน CPU รวมเพียงราว 50% แต่สไปก์ของทราฟฟิกอันตรายกลับก่อให้เกิดอาการช้าและเหตุขัดข้องของวิกิประมาณ 95%

โครงสร้างที่ยากจะรู้ว่าใครเป็นคนทำ

  • แม้จะเรียกทราฟฟิกนี้ว่า “AI scraper” แต่เพราะทั้งหมดปลอมตัวเป็น Google Chrome จึงยากจะรู้ว่าใครคือผู้รับผิดชอบจริง หรือเอาข้อมูลวิกิไปใช้อะไร
  • ผู้เล่นที่เป็นไปได้มีตั้งแต่นายหน้าข้อมูล การเก็บข้อมูลซ้ำซ้อนของ frontier lab ไปจนถึงโครงการอิสระที่เข้าถึงพร็อกซีที่อยู่อาศัยได้
  • แม้แต่เรื่องที่ว่ากำแพงการเข้ามาทำสิ่งนี้ต่ำลงแค่ไหนก็ยังไม่ชัดเจน
  • หากมีวิธีที่ดีกว่า ผู้ดูแลก็อยากติดต่อผู้เก็บข้อมูลตัวจริงโดยตรงเพื่อหาวิธีที่มีประสิทธิภาพกว่านี้

มาตรการที่ได้ผลจนถึงตอนนี้

  • Cloudflare Challenge และ Anubis

    • การวางเว็บไซต์ไว้หลัง Cloudflare challenge หรือเครื่องมืออย่าง Anubis กลายเป็นแนวทางที่แพร่หลายบนอินเทอร์เน็ตในช่วง 1 ปีที่ผ่านมา
    • มันได้ผลในระดับหนึ่ง แต่ก็มีช่วงที่บอตบางส่วนผ่าน challenge ได้อย่างต่อเนื่อง
    • ดูเหมือนจะมีการแข่งขันทางอาวุธที่มองไม่เห็นระหว่าง Cloudflare กับผู้พัฒนาบอต โดย Cloudflare ชนะราว 90% แต่ 10% ที่เหลือยังสร้างความลำบากในการปฏิบัติการ
    • ผู้อ่านจริงไม่ชอบเห็น challenge ก่อนจะเข้าถึงวิกิ
    • หากต้องการลดผลกระทบต่อคนส่วนใหญ่ ก็จำเป็นต้องมีกฎ heuristic ที่ดีว่า should challenge กับทราฟฟิกแบบไหน แต่การตรวจจับทราฟฟิกอัตโนมัติให้เสถียรนั้นยากในตัวมันเอง

  • กฎไฟร์วอลล์แบบทำมือ

    • ผู้ดูแลส่วนใหญ่ต่างมีกฎไฟร์วอลล์แบบทำมือที่ปรับให้เข้ากับโครงสร้างพื้นฐานและรูปแบบการโจมตีที่ผ่านมา
    • ฟิลเตอร์เหล่านี้มักอิงกับสตริง User Agent, กลุ่ม IP หรือ ASN เฉพาะ
    • Weird Gloop จัดการส่วนใหญ่ที่ระดับ Cloudflare/CDN แต่บางวิกิก็ทำที่ระดับ nginx หรือเว็บเซิร์ฟเวอร์
    • ตอนนี้แค่ User Agent/IP มักไม่พออีกต่อไป จึงต้องดูคุณลักษณะคำขอที่ซับซ้อนขึ้น เช่น เวอร์ชัน HTTP, header, TLS cipher และแฮชที่เกี่ยวข้องกับ ja4

  • มองหา “สิ่งที่คนทำแต่บอตไม่ทำ”

    • มุมมองที่มีประโยชน์คือการหาพฤติกรรมที่ มนุษย์ทำร่วมกัน แต่บอตไม่ทำ
    • วิกิที่ใช้ MediaWiki มีคำขอ HTTP หลายประเภทที่ผู้ใช้เบราว์เซอร์จริงมักสร้างเมื่อใช้งานวิกิ แต่บอตมักไม่สร้าง
    • หากทราฟฟิกกลุ่มหนึ่งที่แยกได้ด้วย header, ja4 hash ฯลฯ เข้าชมบทความจำนวนมาก แต่ไม่สร้างคำขอ “แบบมนุษย์” ตามปกติ ก็เป็นสัญญาณแรงว่าควรใส่ challenge ให้ทราฟฟิกนั้น
    • วิธีมองหา คำขอพฤติกรรมมนุษย์ที่หายไป ในทราฟฟิกบอตนั้นทรงพลังมาก
    • จึงเริ่มสร้างระบบที่วิเคราะห์ทราฟฟิกที่ “ขาดหาย” และเสนอ heuristic แบบ decision tree อัตโนมัติว่า should challenge กับทราฟฟิกใด
    • ในการทดสอบดูเหมือนตรวจเจอ scraper ได้เกือบทั้งหมด แต่ยังไม่ชัดว่าจะเกิด false positive แบบไหนกับผู้ใช้ NoScript, ผู้ใช้ screen reader หรือผู้ใช้บนอุปกรณ์ที่ไม่คาดคิดซึ่งมีพฤติกรรมการท่องเว็บแปลกไป
    • การสร้างและดูแลโครงสร้างพื้นฐาน ML/การวิเคราะห์ข้อมูลของตัวเองอย่างถาวรก็ยังเป็นภาระ

  • เทคนิคตรวจจับที่แปลกกว่านั้น

ทางเลือกสุดโต่งที่แย่สำหรับผู้อ่าน

  • “ตัวเลือกนิวเคลียร์” สำหรับบล็อก AI scraper กลับสร้างความเสียหายต่อผู้ใช้จริงมากกว่า
  • วิธีที่พบได้บ่อยอย่างหนึ่งคือบังคับให้ล็อกอินก่อนดูหน้าที่อาจมีต้นทุนการสร้างสูง
  • Fandom ใช้มาตรการนี้กับทุกวิกิเมื่อไม่กี่เดือนก่อน
  • อีกวิธีคือแสดง Cloudflare challenge กับทุกทราฟฟิก
  • จากมุมของเว็บมาสเตอร์มันเข้าใจได้ แต่ไม่ดีต่อสุขภาพระยะยาวของวิกิและชุมชน
  • บทเรียนสำคัญที่ได้จากการสร้างชุมชนวิกิมา 16 ปี คือวิธีที่ดีที่สุดในการดึงผู้มีส่วนร่วมรายใหม่คือ ลดแรงเสียดทาน
  • ต้องทำให้การแก้ไขง่ายขึ้น ทำให้การสำรวจโครงสร้างภายในวิกิง่ายขึ้น และลดกำแพงระหว่างผู้อ่านกับผู้แก้ไข
  • เทคนิคแอนติบอตแบบสุดโต่งกลับสร้างแรงเสียดทานใหม่ และนำไปสู่ผลลัพธ์ที่คาดเดาได้
  • หลัง Fandom ซ่อน “หน้าภายใน” จากผู้อ่านที่ไม่มีบัญชีมากกว่า 95% พบว่าการมีส่วนร่วมของผู้ใช้ใหม่ทั้งระบบ Fandom ลดลงราว 40%
  • จึงยากจะมองว่า trade-off นี้คุ้มค่า

ทิศทางต่อจากนี้

  • Weird Gloop ยังคงโฮสต์วิกิต่อไป และยังคงช่วยวิกิที่ต้องการย้ายออกจาก Fandom ต่อไปเช่นกัน
  • ในระยะยาว “AI Overviews” อาจฆ่าท่อส่งที่เปลี่ยนผู้อ่านวิกิให้กลายเป็นผู้ร่วมแก้ไขวิกิได้ แต่ประเด็นนี้ขอแยกไว้ต่างหาก
  • คนรู้จักบางส่วนมองว่าคลื่นบอตอาจเป็นผลดีกับ Weird Gloop แต่ถ้าผู้คนไม่สามารถโฮสต์วิกิได้อย่างง่ายดาย อินเทอร์เน็ตก็จะแย่ลง
  • สถานการณ์ที่การโฮสต์วิกิอย่างเสถียรต้องพึ่ง on-call rotation, วิศวกร ML และผลิตภัณฑ์ระดับเอนเทอร์ไพรซ์ เป็นข่าวร้ายมากสำหรับชุมชนวิกิอิสระ
  • การแข่งขันทางอาวุธระหว่างเจ้าของบอตกับเว็บมาสเตอร์มีแนวโน้มจะดำเนินต่อไป จนกว่าจะมีวิธีที่ชาญฉลาดในการเปลี่ยนแรงจูงใจเชิงโครงสร้างของการ scrape
  • crawling API ใหม่ของ Cloudflare อาจเปลี่ยนสมการได้ หากการใช้ API ง่ายกว่าการสร้างระบบของตัวเองที่เพิกเฉย robots.txt และก่อปัญหา
  • ถ้าไม่มีการ scrape เลยย่อมดีกว่า แต่การย้อนสิ่งที่เกิดขึ้นไปแล้วคงทำได้ยาก

ความจำเป็นของการพูดคุยและความร่วมมือแบบเปิดเผย

  • ผู้ดูแลหลายพันคนต่างดูแลเว็บไซต์ของตัวเอง และกำลังพยายามหาเทคนิคที่ฉลาดกว่าสำหรับรับมือบอต
  • ในการพูดคุยแบบไม่เปิดเผยกับผู้ดูแลระบบคนอื่นๆ มีไอเดียที่ดีและเฉพาะเจาะจงมาก และก็น่าจะมีการสนทนากันมากมายใน Slack, Discord และกลุ่มเล็กๆ
  • จำเป็นต้องมี การพูดคุยแบบเปิดเผย มากขึ้นเกี่ยวกับรายละเอียดเชิงปฏิบัติการจริง
  • ผู้ดูแลระบบจำนวนมากยังไม่ตระหนักมากพอว่าปัญหาที่ตัวเองเจอนั้นแทบเหมือนกับของผู้ดูแลรายอื่น
  • ไม่ใช่ทุกคนจะอยากเปิดเผยวิธีป้องกันของตัวเอง และก็มีความกังวลว่าหากเปิดเผยแล้วอาจเสียความได้เปรียบ
  • ถึงอย่างนั้น หากช่วยให้ผู้คนมาร่วมกันคิด ก็อาจคุ้มที่จะยอมรับความเสี่ยงที่ประสิทธิภาพของบางยุทธวิธีจะลดลง
  • ผู้ดูแลระบบที่รับมือกับ AI scraper ควรแชร์วิธีที่ได้ผลในพื้นที่ที่เหมาะกับตน
  • บริษัทที่ขายผลิตภัณฑ์แก้ปัญหาบอตควรเผยแพร่กรณีศึกษาที่มีข้อมูลเชิงปฏิบัติจริงเกี่ยวกับอัตรา precision and recall มากกว่านี้ ภายใต้สภาพแวดล้อมที่ไม่ประดิษฐ์ขึ้น
  • ผู้ที่ต้องตัดสินใจซื้อให้ความสำคัญกับผลลัพธ์จริง ไม่ใช่แค่การติ๊กเช็กบ็อกซ์ฟีเจอร์
  • หากคุณดูแลวิกิหรือเว็บไซต์อิสระและอยากพูดคุยเรื่องการตรวจจับบอต สามารถติดต่อได้ทางอีเมลหรือข้อความ Discord

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

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

 
xguru 39 분 전

โดยพื้นฐานแล้ว GeekNews เองก็มีครอว์เลอร์เข้ามาจำนวนมหาศาลเช่นกัน จึงต้องนำวิธีการหลากหลายมาใช้ทั้งเพื่อบล็อกและเพิ่มประสิทธิภาพด้านต้นทุน บอต AI ฝั่งจีนครอว์ลหนักกันอย่างรุนแรงจริง ๆ

แต่ปัญหาก็คือ หากจะบล็อกฝั่ง CDN กลับมีค่าใช้จ่ายเกิดขึ้นด้วยเหมือนกัน
 
GN⁺ 2 시간 전
ความคิดเห็นจาก Lobste.rs

  • ลองใช้ชาเลนจ์ proof-of-wait เพื่อชดเชยข้อเสียของ Anubis แล้วได้ผลค่อนข้างดี
    โดยพื้นฐานคือ ถ้าอัตราคำขอรวมยังต่ำกว่าเกณฑ์ก็จะปิดตัวกรองไว้ แต่ถ้าเกินเกณฑ์ก็จะให้ผู้ใช้รอ N วินาทีก่อนจึงไปต่อได้
    หลังจากนั้นจะออกโทเคนที่ผูกกับ IP นั้น เพื่ออนุญาตให้ส่งคำขอได้เพียงเล็กน้อยภายในเวลาหมดอายุ และตัวโทเคนเองก็มีการจำกัดอัตราด้วย
    ถ้ายังมีคำขอที่สำเร็จเข้ามาเรื่อย ๆ เวลารอก็จะค่อย ๆ เพิ่มขึ้น
    ค่อนข้างประสบความสำเร็จ และเป็นการ ลดประสิทธิภาพแบบค่อยเป็นค่อยไป โดยไม่ทำให้อุปกรณ์มือถือเสียเปรียบเกินไป แถมยังทำงานได้แม้ไม่มี JavaScript

    • เคยเห็นวิธีนี้ทำงานบน marginalia.nu และชอบตรงที่มันไม่เปลืองแบตมือถือไปกับ proof-of-work
    • ถ้านี่เป็นส่วนหนึ่งของโค้ดที่เปิดเผยต่อสาธารณะ ก็อยากได้ ลิงก์ซอร์สโค้ด ของวิธีที่ใช้ทำสิ่งนี้
    • เจ๋งดี สงสัยว่ามีความพยายามจะทำแนวทางแบบนี้ให้เป็นส่วนหนึ่งของ TLS หรือไม่ ให้ความรู้สึกคล้ายกับสิ่งที่ draft-venhoek-tls-client-puzzles-00 พยายามทำกับชาเลนจ์ proof-of-work
      ของแบบนี้น่าจะอยู่ใน เลเยอร์ที่ต่ำกว่า มาก เช่น TLS หรือแม้แต่ IP stack ของระบบปฏิบัติการ
      ยังไม่เคยคิดเรื่อง proof-of-wait ลึกนัก แต่สำหรับผู้ใช้จริงแล้วมันไม่แย่กว่าสำหรับผู้ใช้ที่ถูกต้องตามกฎหมายเมื่อเทียบกับสแครปเปอร์อัตโนมัติหรือ? คนจะหงุดหงิดกับการรอ แต่สแครปเปอร์แค่เก็บโทเคนไว้แล้วกลับมาใหม่หลัง N วินาทีก็พอ
      ส่วน proof-of-work ก็มีทั้งข้อดีข้อเสียเหมือนกัน แต่อย่างน้อยก็เพิ่มต้นทุนจริงให้สแครปเปอร์ตามขนาดการใช้งาน
    • สงสัยว่าตั้งค่าได้ง่ายไหม สนใจอยากใช้กับวิกิของตัวเองด้วย
    • ดูเป็นแนวทางที่มีประโยชน์ สงสัยว่าจะมีแผนเขียนรายละเอียดเพิ่มเติมหรือไม่
      proof-of-wait อาจช่วยให้ คนที่กังวลกับ proof-of-work สบายใจขึ้นได้

  • สำหรับหน้าพิเศษบางหน้า วิธีที่ให้เข้าถึงได้เฉพาะไคลเอนต์ที่เคยล็อกอินหนึ่งครั้งและมีคุกกี้นั้นตั้งอยู่ ไม่เช่นนั้นก็ปฏิเสธไปเลย ก็ทำงานได้ค่อนข้างดี
    เพราะครอว์เลอร์ส่วนใหญ่มักเล็งหน้าพิเศษเพื่อไล่เก็บวิกิ จึงจำกัดให้เฉพาะผู้ใช้ที่ล็อกอินได้
    ในการตั้งค่านี้ วิกิไม่ได้อนุญาตให้สร้างผู้ใช้
    <If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )"> ErrorDocument 403 "Access denied, please login."
    Require all denied
    </If>
    วิธีนี้ลดภาระของระบบเราได้มาก ก่อนหน้านี้มีช่วงพีกที่หน้าพิเศษถูกครอว์ลหนักจนวิกิใช้งานแทบไม่ได้อยู่บ่อย ๆ
    นอกจากนั้นก็แบน user-agent ของ AI crawler ที่รู้จักด้วย 403 ไปตรง ๆ และบล็อกช่วง IP บางส่วนอย่างของ Alibaba หรือ Amazon Cloud
    น่าสนใจตรงที่ฝั่งนั้นสังเกตเห็น พอจำกัดการไล่เก็บหน้าผ่านมุมมอง Diff ก็เปลี่ยนมาลองแบบเดียวกันผ่านมุมมอง MobileDiff
    มีไล่กันไปมาสักพัก แต่ช่วงหลายเดือนหลังมานี้ก็รันได้ราบรื่นด้วยวิธีนี้

    • การบล็อกตาม user-agent จริง ๆ แล้วแทบจะเป็นหนึ่งในวิธีที่แย่ที่สุดเท่าที่ทำได้
      ถ้าบล็อกด้วย user-agent ครอว์เลอร์ก็จะกลับมาลองใหม่โดยใช้ user-agent ที่ดูเหมือนคน แล้วสำรวจเว็บต่อ
      ถ้ามันตัดสินได้ว่าตัวกระตุ้นการบล็อกคือ user-agent มันจะเข้า โหมดนรก ทำให้ระบุตัวได้ยากขึ้นมากและไล่ถล่มเว็บจนกว่าจะพัง
      การบล็อกช่วง IP ก็ช่วยได้ แต่ไม่พอและจับได้ไม่หมด เพราะมันไปครอว์ลผ่านพร็อกซีจากมัลแวร์บนมือถือ
      ถ้าไม่ไปบล็อกตั้งแต่แรก ส่วนใหญ่ก็ยังค่อนข้างสงบเสงี่ยมอยู่
      เพราะงั้นเคล็ดลับคือแทนที่จะบล็อก ก็ป้อนข้อมูลขยะที่สร้างได้ถูก ๆ ให้มันกิน โดยไม่ไปกระตุ้นโหมดนรก และฉันใช้ https://iocaine.madhouse-project.org/
    • เผื่อไว้เป็นข้อมูล เรื่องนี้ทำได้ด้วยสิทธิ์ของ MediaWiki เช่นกัน ตั้งค่าเริ่มต้นให้ปฏิเสธทุกสิทธิ์ แล้วค่อยเพิ่มสิทธิ์ให้อ่านหน้าในเนมสเปซหลักกลับคืนเฉพาะผู้ใช้นิรนาม ก็จะตัดเกมแมวจับหนูไปได้
      แต่ถ้าทำแบบนั้น MediaWiki จะต้องเสิร์ฟคำตอบเองโดยตรง จึงมีข้อดีของการให้ Apache จัดการแทนอยู่ด้วย
    • สงสัยว่ามันสังเกตเห็นทันทีจริงไหม ฉันเดาว่าคนเขียนสแครปเปอร์คงเตรียม เทคนิคสำรอง หลายแบบไว้แล้ว และเมื่อเริ่มได้ 403 บอตก็คงลองทริกถัดไปตามลำดับเอง

  • นอกประเด็นนิดหน่อย แต่ Weird Gloop เป็นบริการที่ยอดเยี่ยมมาก คุณภาพของวิกิที่ดูแลอยู่สูงมาก และการย้ายคอนเทนต์ที่แฟน ๆ ทำจากแพลตฟอร์มอันเลวร้ายของ Fandom ก็เป็นประโยชน์ต่อโลก

  • Gergely Nagy, a.k.a. algernon และผู้พัฒนา iocaine จัดการปัญหานี้มาระยะหนึ่งแล้ว และน่าจะมีข้อมูลเชิงลึกที่เป็นประโยชน์ต่อ Weird Gloop มาก

  • ไม่อยากพูดแบบนี้ แต่ข้อเสนอที่ว่าให้ จูนตามพฤติกรรมของมนุษย์ น่าจะย้อนมาทำร้ายในภายหลัง
    บอตจะเริ่มขอทุก static asset ของหน้า และถือว่านั่นเป็นส่วนหนึ่งของพฤติกรรมที่ใช้ระบุว่าเป็นคน
    เกมนี้น่าสนใจดีนะ ศาสตราจารย์ Falken

  • ถ้าสแครปเปอร์เข้าถึงหน้าแบบนี้ด้วยการไล่ตามลิงก์ <a href=...> ปกติแบบรีเคอร์ซีฟ ก็น่าจะเบี่ยงมันอย่างนุ่มนวลได้โดยทำให้หน้าที่แพงและแคชไม่ได้ เช่น diff history เข้าถึงได้เฉพาะผ่านการ submit <form method="POST" action=...>
    แบบนี้ไม่ได้บล็อกอะไรเลย และจริง ๆ ก็เป็นผลดีกับสแครปเปอร์เองด้วย เพราะจะได้ไม่ต้องกลืนกิน ข้อมูลซ้ำซ้อน แบบแทบไร้ขีดจำกัดด้วยการไล่ตามรีเคอร์ซีฟ
    ผู้ใช้ทั่วไปก็น่าจะแทบไม่รู้สึกถึงความต่าง และเมื่อเทียบแรงที่ลงไปกับผลที่ได้ก็ดูน่าสนใจ สำหรับผู้ใช้นิรนามอาจดีกว่า Anubis
    ทั้งหมดนี้ตั้งอยู่บนสมมติฐานว่าสแครปเปอร์จะไม่ submit ฟอร์ม HTTP ที่เป็น method="POST"
    ถ้ามันไม่จริงเป็นส่วนใหญ่ ก็น่าจะได้เห็นพาดหัวไปแล้วว่า AI scraper ส่งการแก้ไขแบบไม่ล็อกอินจำนวนมากจนเปลี่ยนเนื้อหา Wikipedia ให้กลายเป็นขยะแบบสุ่ม

    • ถ้าทำแบบนั้น คำตอบก็จะ แคชไม่ได้ ไปด้วย ซึ่งอาจเป็นปัญหาถ้าพึ่งพา CDN
      สงสัยว่าบอตจะกด <form method="GET"> ด้วยไหม แบบนี้เข้ากับแคชได้ดีและอาจบังคับให้ครอว์เลอร์ต้องมีลอจิกเพิ่ม

  • 95% ของทราฟฟิกบล็อกเล็ก ๆ ของฉันมาจาก LLM scraper จากสิงคโปร์และจีน

  • ผ่านมาตั้งหลายปีแล้ว ไม่มีใครหา IP ของ ISP เล็ก ๆ สักตัวด้วยการไล่ดูแล้วติดต่อหรือไปหาถึงที่ได้เลยหรือ? ไม่มีใครไปถามผู้ใช้อย่างสุภาพว่าให้ตรวจเครื่องคอมพิวเตอร์ได้ไหม? ไม่มีใครหาคำตอบได้จริง ๆ หรือว่าซอฟต์แวร์อะไรเป็นตัวครอว์ล?
    ถ้าผู้ดูแลเว็บยังทำแค่นี้ไม่ได้ ฉันก็ไม่อยากใส่ใจอีกต่อไป พยายามหลีกเลี่ยง การติดต่อกันระหว่างมนุษย์แบบสกปรก ๆ กันสุดชีวิต สุดท้ายก็ได้บอตมาแทน
    และบอตที่รันอยู่บน residential botnet ก็มีทรัพยากรคอมพิวต์มากพอที่จะผ่าน CAPTCHA หรือ Anubis ได้เป็นครั้งคราวอยู่แล้ว
    ทางฝั่งเซิร์ฟเวอร์ไม่มีทางชนะได้ถาวร เพราะผู้ใช้ของเครื่องนั้นก็สร้างทราฟฟิกที่ถูกต้องตามกฎหมายด้วย
    ดังนั้นถ้าไม่ได้ต้องการ remote attestation ก็ต้องตามไปถึง IP พวกนั้น

    • ดูเหมือนจะประเมินขนาดของ residential botnet ต่ำไปมาก
    • ปัญหาคือทราฟฟิกมาจาก IP ที่ต่างกันนับหมื่น
      ต่อให้ไม่คิดปัญหาเรื่องค่าน้ำมันจากการต้องขับรถไปทั่วโลก มันก็กลายเป็น ปัญหาเซลส์แมนเดินทาง ขนาดใหญ่
    • เป็นมุมมองที่แย่อย่างน่าตกใจจริง ๆ
      ความคิดที่ว่าบอตไม่กี่ตัวจะทำให้ผู้ดูแลระบบขับรถไปไหนก็ได้ตลอดสุดสัปดาห์เพื่อให้มันทำตัวสุภาพขึ้นอีกนิดนั้นชวนขำ โดยเฉพาะเมื่อส่วนใหญ่มาจาก ISP รายใหญ่หรือ ISP ต่างประเทศ
      ถึงขั้นสงสัยเลยว่าไปเสพอะไรมาถึงคิดแบบนี้
      ส่วนเรื่องว่าทุกวันนี้ซอฟต์แวร์อะไรเป็นตัวครอว์ล? ก็แค่มีคนสั่งแชตบอตว่า “ช่วยสร้างตัวสแครปสิ่งนี้ให้หน่อย” แล้วสแครปเปอร์แต่ละตัวก็ถูกสร้างขึ้นมาแยกกันแบบนั้น
    • คำถามแบบ “ไม่มีใครเลยหรือ” จะสมเหตุสมผลก็ต่อเมื่อบอกได้ว่าใครกันแน่ที่มีทั้งความสามารถ แรงจูงใจ หรือความรับผิดชอบจะทำเรื่องนั้น
      ไม่อย่างนั้นก็แค่โทษจักรวาลแบบนามธรรม
    • การติดต่อ ISP รายเล็กแล้วตามไปหาถึงที่แทบไม่สมจริง
      มั่นใจได้เลยว่าผู้ให้บริการส่วนใหญ่ไม่สนใจเลยว่า IP ของตัวเองถูกใช้สแครปเว็บไหนอยู่
      และมั่นใจได้เหมือนกันว่าผู้ให้บริการพวกนั้นจะไม่ยอมบอกที่อยู่ที่ผูกกับ IP ให้
      สิ่งที่ได้ผลกว่ามากคือ ทิ้งทราฟฟิกทั้ง ASN ที่เกี่ยวข้องกับผู้ให้บริการหลายรายอย่าง Alibaba หรือ AWS ไปเลย
      มันไม่ใช่ตัวเลือกที่ทำได้เสมอไป เช่น ถ้าเป็นบล็อกที่มี Atom feed ก็อาจบล็อกโปรแกรมอ่านฟีดไปด้วย
      แต่ในหลายกรณีก็ลดทราฟฟิกขยะได้ 80%

  • มีใครรู้ไหมว่าทำไมพฤติกรรมแบบนี้ถึงเกิดขึ้น โดยเฉพาะสงสัยว่าทำไมถึงมี สไปก์

    • สมมติฐานที่ได้ยินมาคือ botnet มีความเชื่อถือได้น้อย และคนที่ขายการเข้าถึง botnet ผ่าน residential proxy ก็ชดเชยความไม่เสถียรนั้นด้วย คำขอซ้ำซ้อน
      ไม่รู้จริงไหม แต่อย่างน้อยก็ดูพอฟังขึ้น
      ถ้าไม่เข้าใจอินฟราฯ มากกว่านี้ก็คงพูดยาก อาจเป็นข้อจำกัดของ command-and-control ก็ได้
      ถ้า botnet ถูกสร้างมาเพื่อ DDoS โครงสร้างของมันอาจไม่ได้ละเอียดพอสำหรับการควบคุมแบบประณีตก็ได้