Anubis ขัดขวางใครกันแน่?

 (fzakaria.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Anubis ที่บังคับให้ทำ Proof-of-Work ก่อนเข้าถึงผ่าน HTTP กลับสร้างต้นทุนต่อเนื่องที่หนักกว่าสำหรับผู้ใช้ทั่วไป อุปกรณ์สเปกต่ำ และไคลเอนต์ที่ไม่รองรับ JavaScript มากกว่าสำหรับ AI scraper
  • anubis-fetch ที่ LLM สร้างขึ้นสามารถแก้ Proof-of-Work ได้โดยตรง และหากจำเป็นก็รัน Chromium พร้อมเลียนแบบลายนิ้วมือ TLS/JA3 ของ Chrome เพื่อผ่านแม้กระทั่งการบล็อกแบบกำหนดเองของ Cloudflare
  • Scraper สามารถแคชและนำคุกกี้ที่ออกให้กลับมาใช้ซ้ำ ทำให้เฉลี่ยต้นทุนออกไปได้ครอบคลุมหลายคำขอ แต่คนจริงต้องยอมเสียเวลารอหลายวินาทีและแบตเตอรี่ทุกครั้งที่เข้าใช้งาน
  • ระดับความยากเริ่มต้น 4 ต้องใช้ 65,536 แฮช โดยเฉลี่ย; การทำงานแบบเนทีฟใน Go ใช้เวลาประมาณ 1.3ms, JavaScript บนเบราว์เซอร์ประมาณ 130ms แต่เวลารอที่ผู้ใช้รับรู้จริงอยู่ราว 1~5 วินาที
  • หากสมมติว่าเวลาที่ผู้ใช้รับรู้ต่อครั้งคือ 2 วินาที และใช้พลังงาน 20J การท้าทาย 1 ล้านครั้งต่อวันจะกินทรัพยากรราว 23 คน-ปี·2MWh ต่อปี และ 100 ล้านครั้งต่อวันจะกินราว 2,300 คน-ปี·200MWh

AI ข้าม Anubis ได้แล้ว

  • ระหว่างทำแพตช์ให้ binfmt_misc ของ Linux kernel รองรับ $ORIGIN ใน PT_INTERP ผ่าน bpf ผู้เขียนได้ขอให้ LLM อ่าน เธรดใน Linux kernel mailing list
  • เว็บไซต์ lore.kernel.org ได้ติดตั้ง HTTP proxy อย่าง Anubis ซึ่งบังคับให้ทำ Proof-of-Work ก่อนเข้าถึงทรัพยากร
  • LLM ได้สร้าง anubis-fetch ขึ้นมาเพื่อจัดการข้อจำกัดนี้
    • ขั้นแรกจะพยายามแก้ Proof-of-Work แบบเนทีฟ และหากล้มเหลวจะเปิด URL ด้วย Chromium
    • ใช้ req เพื่อเลียนแบบ ลายนิ้วมือ TLS/JA3 ของ Chrome จริง ทำให้ผ่านการบล็อกแบบกำหนดเองของ Cloudflare ได้ด้วย
    • anubis-fetch <URL> จะส่งออก HTML ไปยัง standard output และตัวเลือก --text จะส่งออกเป็นข้อความล้วนที่อ่านง่าย
  • AI และบอตที่ Anubis ตั้งใจจะสกัดกั้น สามารถข้ามได้ง่ายเมื่อเพิ่มการรองรับ Proof-of-Work เพียงครั้งเดียว
    • Scraper สามารถแคชและใช้คุกกี้ที่ได้จากการแก้ challenge ซ้ำ ทำให้เฉลี่ยต้นทุนกระจายไปยังหลายคำขอได้
    • ในทางกลับกัน มนุษย์ต้องรอ spinner และใช้แบตเตอรี่ทุกครั้งที่เข้าเว็บ และไม่สามารถแบ่งต้นทุนนี้กับผู้ใช้อื่นได้
    • ยิ่งเป็นอุปกรณ์สเปกต่ำหรือสมาร์ตโฟน ภาระยิ่งมากขึ้น และ w3m·lynx·โปรแกรมอ่านหน้าจอ·โปรแกรมอ่าน RSS ที่ไม่ใช้ JavaScript ก็เข้าถึงไม่ได้
  • กลไกที่ตั้งใจจะกัน AI แต่กลับถูก AI ข้ามได้ง่าย ขณะที่ยังคงโยนต้นทุนให้คนและเว็บแบบเปิดอย่างต่อเนื่อง จึงทำงานในลักษณะของ ภาระที่ถดถอยย้อนแย้ง

ต้นทุนด้านเวลาและพลังงานที่ Proof-of-Work สร้างขึ้น

  • ระดับความยาก d คือจำนวนอักขระเลขฐานสิบหกศูนย์นำหน้าที่แฮชต้องมี และปริมาณงานคาดหวังต่อการแก้หนึ่งครั้งคือ W = 16^d แฮช
    • ค่าเริ่มต้นที่พบบ่อยอย่างระดับความยาก 4 ต้องใช้ 65,536 แฮช
      • การทำงานแบบเนทีฟใน Go ที่ประมาณ 50 MH/s: ราว 1.3ms
      • JavaScript บนเบราว์เซอร์ที่ประมาณ 0.5 MH/s: ราว 130ms
      • เวลาที่ผู้ใช้รับรู้จริง รวมการโหลดหน้า การรัน worker และการรีโหลด: ราว 1~5 วินาที
    • ระดับความยาก 5 ต้องใช้ 1,048,576 แฮช
      • การทำงานแบบเนทีฟใน Go: ราว 20ms
      • JavaScript บนเบราว์เซอร์: ราว 2 วินาที
      • เวลาที่ผู้ใช้รับรู้จริง: ราว 5~15 วินาที
  • สมมติจำนวนครั้งในการแก้ Anubis challenge ต่อวันทั่วโลกเป็น C, เวลาที่ผู้ใช้รับรู้ต่อครั้ง t = 2วินาที, และพลังงานอุปกรณ์รวมหน้าจอและ CPU เป็น E = 20J
    • เวลาของมนุษย์ต่อปีคำนวณเป็น C × t × 365 / 3.15×10⁷
    • พลังงานต่อปีคำนวณเป็น C × E × 365 / 3.6×10⁶kWh
  • ภายใต้สมมตินี้ ต้นทุนรายปีมีดังนี้
    • วันละ 1 ล้านครั้ง: ราว 23 คน-ปี, ราว 2MWh
    • วันละ 10 ล้านครั้ง: ราว 230 คน-ปี, ราว 20MWh
    • วันละ 100 ล้านครั้ง: ราว 2,300 คน-ปี, ราว 200MWh
  • ตัวเลขทั้งหมดเป็นเพียงการประมาณคร่าว ๆ และไม่ได้มีไว้เพื่ออ้างประเด็นสิ่งแวดล้อม เพราะ bot farm และเครื่องมือ AI ใช้พลังงานมากกว่านี้อีกหลายลำดับขั้น
  • เวลาสำหรับหุ่นยนต์ไม่ใช่ข้อจำกัด แต่เวลาของมนุษย์มีจำกัด ดังนั้นผู้ใช้จึงต้องเสียเวลารอเพื่อเข้าถึงเว็บไซต์ร่วมกันเป็นจำนวนมาก ทั้งที่ก่อนยุค AI ไม่เคยมีต้นทุนลักษณะนี้

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

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

    • Anubis น่าจะได้ผลดีในการป้องกันสถานการณ์ที่สแครปเปอร์ซึ่งใช้พร็อกซีที่อยู่อาศัยทำให้เซิร์ฟเวอร์ล่มได้ คำขอจากเอเจนต์แต่ละตัวไม่ได้ต่างจากการที่ผู้ใช้เปิดดูเว็บไซต์ด้วยตนเองมากนัก
      แต่สำหรับเป้าหมายนี้ Anubis ถูก ออกแบบมาเกินความจำเป็น แค่ให้กดปุ่มหนึ่งครั้งแล้วออก access cookie ก็ให้ผลป้องกันแบบเดียวกันได้ และเมื่อทดลองทำใน Apache ก็พบว่าใช้งานได้ดีพอโดยไม่ต้องมี proof-of-work ที่ซับซ้อน
    • เป้าหมายไม่ใช่สแครปเปอร์ของบริษัท LLM โดยเฉพาะ แต่คือ เว็บสแครปเปอร์ห่วย ๆ และใช้งานในทางที่ละเมิดโดยรวม เพียงแต่มีการคาดเดาว่าบางส่วนในนั้นดำเนินการโดยบริษัท LLM
    • ทราฟฟิกที่เพิ่มขึ้นบนเว็บไซต์ไม่ได้มาจาก OpenAI, Anthropic, Meta และที่คล้ายกัน แต่เป็นจาก ผู้เล่นรายอื่น จึงไม่ชัดเจนว่าจะนิยามอะไรว่าเป็นบริษัท LLM
      แม้แต่ในงาน data mining ของผมเอง เครื่องมือ scraping สมัยใหม่ก็เก่งพอจะหลบสิ่งกีดขวางแทบทั้งหมดได้ และ Anubis เองก็หลบได้ง่ายเช่นกัน
    • ผมอยากบล็อก การเข้าถึงแบบ RAG ต่อเว็บไซต์ส่วนตัวและซอฟต์แวร์ของผมด้วย จึงใช้การบล็อก user agent ขั้นพื้นฐาน ลองให้ ChatGPT เข้าถึงเว็บไซต์โดยตรงเพื่อทดสอบแล้ว พบว่าบล็อกได้ดี
      แม้คอนฟิกแบบเฉพาะทางมาก ๆ อาจหลุดรอดไปได้ แต่เป้าหมายคือกันคู่กรณีที่ขี้เกียจ ไม่ใช่คู่กรณีที่มุ่งร้ายจริงจัง
    • สิ่งที่ Anubis บล็อกได้เป็นหลักคือ สแครปเปอร์ Python requests แบบพื้นฐาน ที่ปลอมตัวเป็น Chrome อย่างลวก ๆ ส่วนผลการบล็อกอื่น ๆ ก็แทบจะเป็นของแถม

  • Anubis ไม่ได้คัดกรองบอต แต่เป็นการ จำกัดอัตราคำขอของไคลเอนต์

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

  • ถ้าดูจากผลการใช้งานจริง ก็ยากจะเห็นด้วยกับข้อสรุปของบทความ ผมให้บริการเว็บไซต์ของ homelab ผ่าน public proxy ของ fly.io และ Tailscale forwarding แล้วต้องจ่าย ค่าแบนด์วิดท์ราว 20 ดอลลาร์ ต่อเดือนเพราะสแครปเปอร์รวมถึงของ Facebook
    หลังใช้ Anubis กับพร็อกซี ก็กลับมาอยู่ในโควต้าฟรีได้ ต่อให้ถ้าจะหลบก็ยังหลบได้ก็ไม่เป็นไร เพราะแค่บล็อกทราฟฟิกเก็บข้อมูลปริมาณมากจากผู้ไม่หวังดีไม่กี่รายที่เมิน robots.txt ได้เป็นส่วนใหญ่ก็เพียงพอแล้ว

  • สำหรับงาน scraping ที่ใช้บอตเน็ตจากอุปกรณ์สเปกต่ำอย่าง smart TV นั้น proof-of-work ของ Anubis ดูเหมือนอาจเป็นอุปสรรคจริงได้ เรื่องนี้มีพูดถึงเล็กน้อยใน https://lobste.rs/s/kpaxih/update_on_scraper_situation

    • ถ้าผมไม่ได้เข้าใจผิด smart TV นั้นถูกใช้ เป็นแค่พร็อกซี และไม่ได้เป็นฝ่ายประมวลผล proof-of-work เอง

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

    • ตลอดปีที่ผ่านมา ผมติดอยู่ระหว่าง ทางเลือกประนีประนอมที่เป็นไปไม่ได้ แบบนี้ และผมเองก็ยังหาคำตอบที่ดีไม่ได้

  • มีท่าทีที่แสดงออกอย่างชัดเจนว่าไม่เคารพการตัดสินใจที่คนอื่นเลือก

  • สิ่งที่น่าขยะแขยงที่สุดคือ มันดูเหมือนเป็นการกระทำที่ ละเมิดกฎหมายอย่าง CFAA อย่างชัดแจ้ง แต่กลับปกปิดตัวตนเหมือนบริการ DDoS เชิงอาชญากรรมอื่น ๆ
    จะคาดหวังให้บริษัทที่ทั้งโมเดลธุรกิจพึ่งพาการขโมยผลงานคนอื่นและฟอกโค้ดโอเพนซอร์ส ปฏิบัติตามกฎหมาย ก็เป็นเรื่องน่าขันตั้งแต่ต้น

  • ปกติแล้ว Anubis ไม่ได้บล็อก Dillo แต่ก็อาจถูกบล็อกได้ตามการตั้งค่าเว็บไซต์ ซึ่งน่ารำคาญมากเพราะมันส่งเสริมบรรยากาศแบบ ถ้าไม่มี JavaScript ก็ไม่มีสิทธิ์มีตัวตน: https://paste.rs/jNgwd.png
    ผมกำลังคิดอยู่ว่าจะรวบรวมและดูแลรายการ IP ทั้งหมดที่อยู่ใน residential proxy แล้วบล็อกเป็นระยะเวลาหนึ่งได้หรือไม่ และ ipset อาจรองรับสเกลระดับนี้ได้ จาก log จะเห็นได้ค่อนข้างง่าย เพราะบอตไม่โหลดทรัพยากรอื่นอย่าง CSS หรือรูปภาพเลย แต่จะไล่วนทุกไฟล์ในทุก commit ของ repository ของ Dillo
    ในแต่ละเว็บไซต์อาจเห็นเพียงหนึ่งคำขอต่อ IP แต่มีโอกาสสูงว่า IP เดียวกันจะไปดึงหลายเว็บไซต์ จึงอาจบล็อก IP ที่ถูกรายงานหลายครั้งได้ แทนที่จะตัดการเชื่อมต่อทิ้งเฉย ๆ ควร redirect ไปยังหน้าคำอธิบายบนพอร์ตแยกต่างหาก เพื่อบอกเหตุผลที่ถูกบล็อกและวิธีแก้ไข
    แบบนี้ยังช่วยลดแรงจูงใจในการฝัง backdoor reverse proxy ลงในส่วนขยายเบราว์เซอร์หรือแอปมือถือด้วย เพราะผู้ใช้จะเริ่มถูกบล็อกจริง
    เป็นเรื่องน่าเสียดายที่ต้องพึ่ง ระบบชื่อเสียงของ IP แต่ก็ไม่ค่อยเห็นมาตรการอื่นที่ได้ผล อุปกรณ์ที่อ่อนแอแม้จะลบ botnet command-and-control server ออกแล้ว ก็อาจถูกผู้โจมตีรายถัดไปยึดกลับและดึงเข้า botnet ใหม่ได้อีก

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

    • เหมือนกับที่ผู้เขียนไม่ได้ติดแท็กนั้นเพียงเพราะใช้ compiler หรือ editor ประเด็นของบทความนี้ไม่ใช่ vibe coding แท็ก vibecoding ถูก pushcx เอาออก
    • ตอนโพสต์ บทความระบุชัดว่ามีการทำอะไรบางอย่างเพื่อหลบการบล็อกโดยใช้ vibe coding เลยติดแท็กนั้นไป บทความที่พูดถึง AI coding น้อยกว่านี้ยังเคยถูกติดแท็กด้วยซ้ำ จึงน่าแปลกที่แท็กนี้ถูกลบ แต่สุดท้ายก็ต้องยอมรับว่าเกณฑ์การใช้แท็กนี้ ไม่เคยมีความสม่ำเสมอเลย