Anubis ใช้งานได้จริง

 (xeiaso.net)
3 คะแนน โดย GN⁺ 2025-04-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Anubis ถูกนำไปใช้งานบน policytoolbox.iiep.unesco.org ของ UNESCO ทำให้ได้รับความสนใจมากขึ้นในฐานะตัวอย่างเครื่องมือรับมือบอตที่องค์กรขนาดใหญ่ใช้งาน
  • หลังตรวจสอบแล้วว่า unesco.org เป็นโดเมนทางการของ UNESCO การนำไปใช้งานครั้งนี้จึงถูกมองว่าเป็นกรณีใช้งานจริงของ องค์กรที่เกี่ยวข้องกับ United Nations
  • การใช้งานกำลังขยายวงกว้างขึ้นร่วมกับปลายทางที่ทราบอยู่แล้ว เช่น Linux Kernel Mailing List archives, FreeBSD SVN, SourceHut, FFmpeg, Wine และ GNOME GitLab
  • สถานการณ์ที่องค์กรเหล่านี้นำ Anubis มาใช้ แสดงให้เห็นว่าปัญหา ทราฟฟิกบอต บนอินเทอร์เน็ตอาจรุนแรงกว่าที่คาดไว้
  • Anubis และสแตกที่เกี่ยวข้องยังต้องการเวลาเพิ่มขึ้น และหากมีผู้สนับสนุนเพียงพอ ก็อาจทำงานพัฒนาเต็มเวลาและไปถึงขั้น จ้างงาน ได้

ยืนยันการนำไปใช้งานที่ UNESCO

  • Anubis ถูกนำไปใช้งานบน policytoolbox.iiep.unesco.org ของ UNESCO ซึ่งอยู่ภายใต้ United Nations
  • unesco.org ถูกระบุใน Wikipedia ว่าเป็นโดเมนทางการของ United Nations Educational, Scientific and Cultural Organization
  • ต้องการติดต่อทีมผู้ดูแลระบบของ UNESCO เพื่อตรวจสอบว่ามีปัญหาใดระหว่างการติดตั้งหรือไม่ และทำให้ กระบวนการติดตั้งง่ายขึ้น

กรณีการนำไปใช้งานที่ทราบ และงานในอนาคต

  • กรณี การนำไปใช้งานขนาดใหญ่ ที่ยืนยันแล้วมีดังนี้
    • Linux Kernel Mailing List archives
    • SVN ของ FreeBSD และเร็ว ๆ นี้คือ git
    • SourceHut
    • FFmpeg
    • Wine
    • UNESCO
    • The Science Olympiad Student Center
    • Enlightenment desktop environment
    • GitLab ของ GNOME
  • หากองค์กรขนาดนี้กำลังใช้ Anubis อยู่ ปัญหาทราฟฟิกบอตอาจอยู่ในระดับที่ รุนแรงกว่าที่เคยคาดไว้มาก
  • เช่นเดียวกับกรณีที่ YouTube ครั้งหนึ่งเคยเข้าใกล้ “the inversion” ซึ่งทราฟฟิกจากบอตมีมากกว่าทราฟฟิกจากมนุษย์ คำถามที่ยังเหลืออยู่คือปรากฏการณ์คล้ายกันนี้แพร่กระจายไปทั่วอินเทอร์เน็ตในวงกว้างเพียงใด
  • จำเป็นต้องทุ่มเวลาให้กับ Anubis และสแตกที่เกี่ยวข้องอย่างจริงจัง และหากสามารถหาผู้สนับสนุนได้เพียงพอ ก็จะสามารถทำงานนี้เต็มเวลาและถึงขั้น จ้างงาน ได้
  • หาก Anubis มีประโยชน์ ขอให้สนับสนุนผ่าน Patreon

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

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

 
GN⁺ 2025-04-14
ความเห็นจาก Hacker News

  • บทความที่เกี่ยวข้อง: Anubis: พร็อกซี proof-of-work เพื่อกัน AI crawler (100 points, 23 days ago, 58 comments) https://news.ycombinator.com/item?id=43427679

  • น่าสนุกดีที่ Xe เอาสิ่งที่เมื่อก่อนแทบจะเป็นมุก/โพสต์ไร้สาระ มาทำให้กลายเป็นผลิตภัณฑ์ที่มีประโยชน์จริงได้ เคยบอกเสมอว่า จังหวะเวลาคือทุกอย่าง
    ก็น่าแปลกใจอยู่ที่มีไซต์จำนวนมากขนาดนี้ต้องการหรือจำเป็นต้องใช้มัน เข้าใจปัญหาหน้า Git ที่ช้าของ Git server บางตัวที่ลึกมาก ไม่มีแคช และให้บริการจากดิสก์ช้า ๆ
    UNESCO นี่ค่อนข้างเหนือความคาดหมาย ไซต์ย่อยนั้นมีเอกสารหลายพันฉบับและค่อนข้างใหญ่ แต่เป็นคอนเทนต์แบบ static ก็น่าจะให้บริการได้ง่าย พอลองดูพบว่าเป็น WordPress ที่ deploy แบบหละหลวม บน Apache ไม่มีแคช ไม่มีการบีบอัดคอนเทนต์ และไม่มี HTTP/2·HTTP/3
    น่าจะแก้ให้ให้บริการได้ถูกมากแม้บนเครื่องเล็ก ๆ ได้ไม่ยาก แต่แน่นอนว่าต้องใช้ความเชี่ยวชาญ และความเชี่ยวชาญก็ยังไม่ถูก
    อาจจะถาม LLM ก็ได้ แต่ถ้ายังไม่รู้ด้วยซ้ำว่าควรถามอะไร มันก็ยังช่วยได้ไม่มาก ถ้าไม่รู้ด้วยซ้ำว่าไซต์ช้าตั้งแต่แรก แล้วจะไปถามทำไม คงแค่ได้ยินว่าโดนทราฟฟิกถล่ม แล้วก็ไปหา furry defender มาใช้แทน

    • ที่ว่า “ต้องใช้ความเชี่ยวชาญ และความเชี่ยวชาญก็ยังไม่ถูก” นั้นถูกต้อง แต่ในขณะเดียวกัน คนที่ ตั้งค่า Anubis เป็น น่าจะมีน้อยกว่าคนที่มีประสบการณ์ดูแล WordPress มาก ๆ เลยยังน่าแปลกใจอยู่
      ไม่ได้หมายความว่ามันยากนะ แต่หมายถึงตั้งแต่คนที่รู้ว่ามันมีอยู่ก็มีน้อยแล้ว
      ถ้าให้เดา เหตุผลที่ไม่แตะ WordPress อาจไม่ใช่ปัญหาทางเทคนิค แต่อาจเป็นเพราะไม่อยากยุ่งกับ instance ที่เปราะบาง ปัญหาเรื่องสิทธิ์ในองค์กร หรือผู้ดูแลคิดไปแล้วว่า WP ตั้งค่าไว้ดีอยู่แล้ว
    • ไซต์ของผมที่อยากเอาอันนี้ไปใช้มีบทความเยอะ และด้วย faceted search แบบอิงแท็ก ทำให้จำนวนชุดผสมและหน้าที่เป็นไปได้แทบจะไม่มีที่สิ้นสุด
      อันนี้ไม่มีทางแคชได้ และพวกบอตก็ไม่เคารพไฟล์ robots เลย ขอ URL ไปเรื่อย ๆ แล้วดึงบทความซ้ำ ๆ ด้วยตัวเลขและชุดผสมต่าง ๆ เป็นปัญหาปวดหัวจริง ๆ
    • AI scraper ไม่ได้แค่ทำมาแบบห่วย ๆ แต่ยังจงใจทำ cache invalidation ด้วย
      วิธีแก้ที่เห็นจนถึงตอนนี้มีแค่ Cloudflare, บังคับล็อกอิน, Anubis หรือไม่ก็อินฟราสเกลมหาศาลแบบไร้เหตุผล
      บางไซต์บอกว่า 60% ของทราฟฟิกมาจากบอต และไซต์ที่เล็กกว่าน่าจะมีสัดส่วนสูงกว่านั้นมาก
    • การป้องกัน บอต/การ scrape/DDoS แบบอิง proof-of-work มีมาตั้งแต่ 10 ปีก่อนแล้ว ไม่รู้ว่าทำไมเพิ่งมาแพร่หลายเอาตอนนี้
      ยังจำโปรเจกต์ที่พยายามทำให้ proof-of-work กลายเป็นการคำนวณที่มีประโยชน์ได้ด้วย

  • ถ้าสับสนว่านี่คืออะไร มันคือสิ่งที่ทำมาเพื่อ กัน AI scraping
    “Anubis ใช้โจทย์ proof-of-work เพื่อรับประกันว่าไคลเอนต์กำลังใช้เบราว์เซอร์สมัยใหม่และสามารถคำนวณ checksum แบบ SHA-256 ได้”
    https://anubis.techaro.lol/docs/design/how-anubis-works
    ค่อนข้างเจ๋ง และอาจช่วยโปรเจกต์ของผมสักหนึ่งหรือสองโปรเจกต์ได้

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

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

    • โอ้โห ลืมไปเลยว่ายังทิ้งประโยคนี้ไว้ ตลกดี คิดว่าจะคงไว้แบบนั้นแหละ
    • น่าเสียดายที่ถ้าตัดบริบทออก ประโยคนี้ผิด Anubis ปัดเวลาเป็นหน่วยสัปดาห์ที่ใกล้ที่สุด และถ้าสัปดาห์ข้าง ๆ ก็ยัง valid ด้วย ก็น่าจะเพียงพอ
      ด้วยเหตุผลหลายอย่าง ความคลาดเคลื่อนของการซิงก์นาฬิกา เป็นเรื่องพบได้ทั่วไป คาดหวังไม่ได้ว่าผู้ใช้กลุ่มล่าง 10% จะตรงแม้แต่ระดับวัน และแม้แต่กลุ่มล่าง 25% ก็อาจคลาดเคลื่อนไปได้สัก 5 นาที

  • ภาพหน้า intermediate ที่แสดงระหว่างรอการตรวจของ Anubis เสร็จน่ารักมาก ๆ ผมรู้สึกมาตลอดว่าภาพวาดและตัวละครในบล็อกของ Xe สวย
    นอกเรื่องนิดหนึ่ง ผมสงสัยด้วยว่าสิ่งนี้จะส่งผลต่อ search engine ทั่วไปอย่างไร และต่างจากโซลูชันของ Cloudflare ที่กัน AI crawler อย่างไร ซึ่งมีอธิบายไว้ในหน้า GitHub [1]
    “ถ้าคุณติดตั้งและใช้สิ่งนี้ มีความเป็นไปได้สูงที่บาง search engine จะไม่ index เว็บไซต์ของคุณ นี่ไม่ถือเป็นบั๊กของ Anubis แต่ถือเป็นฟีเจอร์”
    “นี่เป็นการตอบโต้ที่ค่อนข้างเหมือนใช้ระเบิดนิวเคลียร์ แต่บอต AI scraper scrape หนักเกินไปจนไม่มีทางเลือก”
    “ในกรณีส่วนใหญ่ คุณไม่จำเป็นต้องใช้สิ่งนี้ และการปกป้อง origin server บางตัวด้วย Cloudflare ก็น่าจะเพียงพอ อย่างไรก็ตาม ในสถานการณ์ที่ใช้ Cloudflare ไม่ได้หรือไม่อยากใช้ ก็มี Anubis อยู่”
    [1]: https://github.com/TecharoHQ/anubis/

    • ใช่ น่าเสียดายที่ตอนนี้มันกัน การ index ของ search ไปด้วย ในอนาคตอาจใส่ IP ของ search engine ไว้ใน allowlist ได้
      แต่บริการอย่าง Google บางทีก็ใช้ IP เดียวกันสำหรับ AI และการ index ของ search
      ถึงอย่างนั้นก็กำลังปรับปรุง เช่น ให้แท็ก Open Graph ผ่านได้ เพื่ออย่างน้อยให้ rich preview ทำงานได้
    • เห็นด้วยว่าภาพหน้า intermediate น่ารัก แต่แค่นึกว่าสักวันหนึ่งอาจมีใครสักคนตัดสินว่ามัน “มีปัญหา” ไม่ทางใดก็ทางหนึ่ง แล้วสุดท้ายคงถูกเอาออก ก็รู้สึกแย่แล้ว

  • ผมอ่านเกี่ยวกับ Anubis มาแล้ว เป็นโปรเจกต์ที่เจ๋งดี น่าเสียดายที่อย่างที่มีคนพูดในคอมเมนต์ ผู้เยี่ยมชมไซต์ต้อง เปิดใช้งาน JavaScript™
    ถ้าเป็นไซต์ที่ยังไงก็ต้องใช้ JavaScript™ เพื่อปรับปรุงประสบการณ์ผู้ใช้ ก็ไม่เป็นไรเลย แต่สำหรับพวกไซต์สแตติกที่ไม่จำเป็นต้องใช้ JS เลย แบบนั้นไม่ค่อยเหมาะ
    ผมทำโซลูชันของตัวเองที่บล็อก “บอตไม่ดี” พวกนี้ได้อย่างมีประสิทธิภาพในระดับเครือข่าย โดยใช้ฐานข้อมูล MaxMind กับ WAF และรีเวิร์สพร็อกซีที่ทำเอง เพื่อบล็อกทั้งเครือข่ายขนาดใหญ่หลายแห่งของ “Big Tech / Big LLM” ในระดับ ASN(BGP)

    • ทราฟฟิกบอตจำนวนมากที่บทความนี้พยายามพูดถึงมาจาก ช่วง IP สำหรับบ้านทั่วไป
      แน่นอนว่ามีทั้งการเล่นตุกติกกับ ASN และการหลอกเรื่องชื่อเสียงไปพร้อมกันด้วย แต่รับมือได้ยากมาก จากการไล่ดูล็อกแบบคร่าว ๆ บอตพวกนี้มักส่งคำขอจาก IP บ้านเฉพาะบางตัวเพียงครั้งเดียว และช่วงเหล่านั้นก็น่าจะเป็นช่วงที่ผู้ใช้มนุษย์จริง ๆ ใช้ด้วย
      พูดง่าย ๆ คือมีความเสี่ยงที่จะบล็อกทราฟฟิกปกติ โซลูชันนี้ก็มีความเสี่ยงเหมือนกัน แต่สำหรับมนุษย์ส่วนใหญ่ ความเสี่ยงจริง ๆ ต่ำกว่ามาก
      คงจะดีถ้าไม่ต้องใช้ JavaScript และรองรับผู้ใช้ที่ปิดมันได้ด้วย แต่ไม่เคยมีลูกค้าหรือผู้ใช้ปลายทางคนไหนบ่นเรื่องที่ต้องเปิด JavaScript เลย
      คนที่คัดค้านข้อกำหนดเรื่อง JavaScript เป็นคนส่วนน้อยที่เสียงดัง และในจำนวนนั้นส่วนใหญ่เมื่อเจอไซต์ที่ต้องใช้ JavaScript ก็แค่เปิดมันอยู่ดี แม้ตอนนั้น ผมคิดว่ามีเพียงน้อยมากที่จะถอนหายใจอย่างพ่ายแพ้
    • สำหรับคนที่สงสัย เครื่องหมายการค้า “JavaScript” เป็นของ Oracle: https://javascript.tm/
    • รู้ได้อย่างไรว่าเป็น LLM หรือ VPN? จะแยก ทราฟฟิก LLM ด้วยฐานข้อมูล MaxMind ได้อย่างไร?
    • มีลิงก์ไปยังโซลูชันที่ทำเองไหม?

  • ชอบไอเดียนะ แต่เมื่อธรรมชาติของโจทย์ชัดเจนขึ้นแล้ว น่าจะต้องลงไปถึง ระดับโปรโตคอล
    ในแง่การเข้าถึงได้ สุดท้ายแล้วงาน proof-of-work ควรกลายเป็นส่วนหนึ่งที่ใกล้กับ TCP มากกว่าให้แต่ละเว็บไซต์ไป implement แยกกันด้วย JavaScript

    • มี Cloudflare PrivacyPass ที่กลายเป็นมาตรฐาน IETF แล้วก็จริง [0] แต่ค่อนข้างแปลก และ reference implementation ก็เป็น กองบั๊ก
      [0] https://datatracker.ietf.org/wg/privacypass/about/
    • แค่ส่งโจทย์แบบใดก็ได้ไปยังแบล็กบ็อกซ์ SPIR-V หรือ MLIR ก็พอ ถ้ารวมการแลกเปลี่ยนโจทย์-คำตอบเข้ากับ HTTP ก็จะทำให้รองรับได้กว้างและใช้การเร่งความเร็วด้วยฮาร์ดแวร์ได้อย่างยืดหยุ่น
      ทางแก้ที่ “ดีพอ” คือ SHA(seed, nonce) ที่ใช้กันแพร่หลายอยู่แล้ว ถ้าบริษัทเทคโนโลยียักษ์ใหญ่ต้องการ เรื่องนี้ก็น่าจะผนวกเข้าไปในเลเยอร์ที่ต่ำกว่าของสแตกได้ง่าย ๆ

  • บนมือถือของผม การแก้การตรวจจับบอตใช้เวลาถึง 5 วินาที

    • ผมใช้ Fennec ซึ่งเป็น Firefox fork จาก F-Droid กับ Pixel 9 Pro XL ที่ระดับความยาก 4 ใช้เวลาประมาณ 8 วินาที
      ส่วนตัวแล้วผมไม่คิดว่าประสบการณ์ผู้ใช้แย่ขนาดนั้น เพราะไม่ต้องทำอะไรเลย ชอบมากกว่า CAPTCHA แน่นอน
    • ดีกว่าลูป CAPTCHA ของ Cloudflare ที่วนไม่รู้จบเยอะ
    • โชคดีนะ ของผมใช้เวลา 30 วินาที
    • ของผมประมาณ 0.5 วินาที น่าสนใจดี

  • ตอนนี้กำลังทำต้นแบบที่เรียกว่า “Enigma Webfont” อยู่ ตั้งใจจะใช้ seed และค่าการหมุนแบบกำหนดเอง ต่อเซสชันผู้ใช้กับเว็บฟอนต์ที่ถูกเสิร์ฟและแคช
    เป้าหมายคือทำให้การเว็บสแครปทำได้ไม่คุ้มในทางปฏิบัติ เพราะต้นทุนการคำนวณ OCR ตอนนี้เป็นเกมแมวจับหนู เลยอยากเปลี่ยนสมดุลเกมสักหน่อย
    ถ้าไม่มีเซสชันผู้ใช้ ซอร์ส HTML ก็แทบไม่มีความหมาย และถ้าทรัพยากรในแคชหายไปด้วยพฤติกรรมแบบ OTP ก็ทำให้เว็บเพจอ่านไม่ได้เช่นกัน
    วิธีนี้ทำให้สร้าง CAPTCHA ได้ในทางปฏิบัติ โดยให้ผู้ใช้ปรับหน้าต่าง seed ในเครื่องจนกว่าจะอ่านคำเฉพาะได้ เช่น “เลื่อนสไลเดอร์จนกว่าจะอ่านคำว่า Foxtrott ได้”
    อยากฟังความเห็นของ Xe มาก ๆ เราจะร่วมมือกันได้ไหม?
    สแตกเทคโนโลยีคือ Go เพราะเป็นภาษาเดียวที่แก้ไฟล์เว็บฟอนต์โดยตรงได้ง่ายและไม่ติดปัญหา

    • แม้จะไม่นับ ปัญหาด้านการเข้าถึงที่เห็นชัด นั่นก็เป็นแค่รหัสแทนที่อย่างมากไม่ใช่หรือ? ถ้ามีคลังข้อความมากพอ การถอดรหัสดูน่าจะง่ายขึ้นมาก
    • ปัญหาไม่ใช่การที่เว็บไซต์ถูกสแครปโดยตัวมันเอง แต่คือ ปริมาณคำขอ ที่ทำให้อินฟราล่มหรือเพิ่มต้นทุน เสิร์ชเอนจินทำแบบนี้มากว่า 30 ปีแล้ว
      การทำให้ข้อความพังไม่น่าช่วยอะไร ยังไงมันก็จะยิงเข้ามาเรื่อย ๆ อยู่ดี จากรูปแบบทราฟฟิก คนที่สร้างบอตพวกนี้ก็แค่... <https://www.youtube.com/watch?v=ulIOrQasR18>
      สำหรับ “อยากฟังความเห็นของ Xe เราจะร่วมมือกันได้ไหม?” เท่าที่ผมเข้าใจ สิ่งที่น่าจะต้องการความช่วยเหลือคือการทำให้โปรเจกต์นี้ยั่งยืนขึ้นทั้งในอนาคตอันใกล้และไกล มากกว่าการใส่ฟีเจอร์เพิ่ม Anubis ดูเหมือนจะทำงานได้ดีเยี่ยมอยู่แล้ว

  • แน่นอนว่ามันทำงานได้ดีในการบล็อกผู้ใช้ที่ปิด JavaScript

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