ทำไมสาวแมวอนิเมะถึงบล็อกการเข้าถึง Linux kernel ของฉัน?
(lock.cmpxchg8b.com)- ไม่สามารถเข้าถึงเว็บไซต์ lock.cmpxchg8b.com ได้
- เกิดอาการเข้าใช้งานไม่ได้เนื่องจาก เซิร์ฟเวอร์ตอบสนองล่าช้า
- มีคำแนะนำให้ตรวจสอบ การเชื่อมต่อเครือข่าย รวมถึงสถานะของเราเตอร์หรือโมเด็ม
- มีการแนะนำให้ตรวจสอบการตั้งค่า พร็อกซี
- เป็นเพียงปัญหาการเชื่อมต่อทั่วไป โดยไม่มีคำอธิบายที่เกี่ยวข้องโดยตรงกับ การเข้าถึง Linux kernel
แจ้งปัญหาไม่สามารถเข้าถึงเว็บไซต์
- เว็บไซต์ lock.cmpxchg8b.com ไม่ตอบสนอง
- มีการแจ้งว่าเกิดปัญหาการเชื่อมต่อหมดเวลา (Timeout)
- แนะนำให้รีบูตอุปกรณ์เครือข่าย (เช่น เราเตอร์, โมเด็ม)
- ขอให้ตรวจสอบการตั้งค่าอนุญาตการเข้าถึงเครือข่ายอีกครั้ง
- มีเนื้อหาแนะนำให้เปลี่ยนการตั้งค่า พร็อกซี ในเบราว์เซอร์ Chromium และแนะนำให้เชื่อมต่อโดยตรง
- ไม่มีคำอธิบายทางเทคนิคโดยตรงว่าการเข้าถึงเคอร์เนลถูกบล็อก หรือเกี่ยวข้องกับภาพตัวละครเฉพาะ (สาวแมวอนิเมะ)
1 ความคิดเห็น
ความเห็นจาก Hacker News
ที่นี่โดยมากเป็นที่รวมตัวของคนที่เชี่ยวชาญด้านเทคโนโลยี เลยชวนให้สงสัยว่าหลายคนไม่เข้าใจหลักการหรือเจตนาของมาตรการป้องกันอย่าง Anubis จริง ๆ หรือแค่แกล้งทำเป็นไม่เข้าใจแล้วทำท่าดูแคลนมันกันแน่
แน่นอนว่าสำหรับนักพัฒนาบอตสแครปข้อมูล AI สักวันหนึ่งก็คงหาวิธีได้ แต่สิ่งสำคัญคืออย่างน้อยมันก็ใช้ได้ผลอยู่ช่วงหนึ่ง
พอฝั่งนักพัฒนาบอตมีวิธีหลบใหม่ ๆ ออกมา ก็จะมีเครื่องมือพิสูจน์ว่า “ไม่ใช่บอต” แบบใหม่เกิดขึ้นอีก
สุดท้ายมันก็ง่าย ๆ แค่นี้: ถ้าใช้วิธีใหม่แล้วทำให้เว็บไซต์ปลอดภัยได้สักเดือนสองเดือน แค่นั้นก็ถือว่าน่าพอใจแล้ว
ดีกว่าต้องมานั่งคิดว่าจะบล็อกทั้งเครือข่ายดีไหม ขณะรับมือกับคำขอหลายสิบครั้งต่อวินาทีมาก
ยกตัวอย่าง ถ้าใส่คำถามในฟอร์มว่า “7+2 เท่ากับเท่าไร?” แน่นอนว่าตัวเก็บข้อมูลคำนวณคำตอบได้ แต่สุดท้ายก็ยังต้องมีมนุษย์เป็นคนบอกสแครปเปอร์ว่า “ต้องทำอย่างไร” อยู่ดี
ผมหวังว่าจะได้เห็นตัวเลขยืนยันว่า PoW (Proof-of-Work) ของ Anubis ส่งผลต่อเว็บไซต์จริง ๆ อย่างไร
เว็บไซต์เล็ก ๆ ที่ผมทำบนเซิร์ฟเวอร์ส่วนตัวไม่ได้ตรวจดูล็อกหรือสถิติมากนัก แต่สักวันเว็บของผมก็อาจโดนครอว์ลแบบดุดันได้เหมือนกัน
จากข้อมูลที่เปิดเผยอยู่ตอนนี้ สิ่งที่เห็นได้มีแค่ประสิทธิภาพของ PoW เอง แต่ไม่รู้ว่ามันช่วยเว็บจริงได้มากแค่ไหน
ในอุดมคติ ถ้ามีสถิติแยกตามชนิดบอตแบบ “บอตของ OpenAI เคยคิดเป็น 17% ของคำขอทั้งหมด แล้วลดจากวันละ 900,000 ครั้งเหลือ 0” ก็คงดีมาก
ลองค้นดูก็มีแต่โพสต์บล็อกที่บอกว่า “Anubis ช่วยกันการครอว์ลได้” เต็มไปหมด แต่ข้อมูลจริงยังน้อย
เพิ่มเติมคือในเธรดด้านล่างผมเจอข้อมูล PDF แบบนี้ แต่ก็ไม่มีการวิเคราะห์ว่าลูกค้าจริงถูกบล็อกไปกี่ราย
อยากเห็นข้อมูลที่หลากหลายกว่านี้
ทั้งที่ทุกวันนี้การเห็นหน้าจอโหลดคั่นของ Cloudflare ตามเว็บไซต์ต่าง ๆ เป็นเรื่องปกติ แต่ผู้คนกลับบ่นว่าแทบไม่มีใครใช้มาตรการป้องกันแบบ Anubis
รู้สึกว่ามันค่อนข้างย้อนแย้ง
ตั้งแต่ Anubis ออกมาใหม่ ๆ ผมก็คิดว่ามันไม่มีประสิทธิภาพ
อย่างแรก สแครปเปอร์ก็รันเบราว์เซอร์เต็มรูปแบบและรอจนหน้าเว็บนิ่งครบอยู่แล้ว ดังนั้นการหลบวิธีนี้จึงไม่ยาก
อย่างที่สอง ถ้า AI จะอ่านหน้าเว็บได้ ต้องใช้การประมวลผลประมาณ 5 วินาทีที่กินพลังถึง 1600W และมือถือของผมก็คงไม่มีทางมีประสิทธิภาพเท่าเครื่องระดับเซิร์ฟเวอร์ จึงอาจใช้เวลานานกว่า 5 วินาทีด้วยซ้ำ
หากต้องทำทั้งหมดนี้พร้อมกัน อุปกรณ์ก็จะร้อนขึ้นและยิ่งไม่มีประสิทธิภาพเข้าไปอีก
ผมคิดว่าไม่ใช่ PoW เองที่กัน AI scraper แต่เป็นขั้นตอนการเข้าถึงเว็บไซต์ที่แปลกของ Anubis ต่างหากที่กันไว้ได้
ถ้านี่เป็นเรื่องจริง Anubis ก็น่าจะใช้ได้ดีพอแม้ตัดฟังก์ชัน PoW ออก เพื่อไม่ให้ผู้เข้าชมที่เป็นมนุษย์จริงต้องเสียเวลามองหน้าจอโหลดหลายวินาทีและสิ้นเปลืองอุปกรณ์
การตรวจง่าย ๆ แบบ 7+2 จะกระทบเฉพาะผู้ใช้ที่กำลังจะส่งอะไรบางอย่าง แต่ Anubis กระทบผู้ใช้ทุกคนแม้จะแค่อ่านเว็บไซต์เฉย ๆ
ผมคิดว่าเป้าหมายหลักของ Anubis คือการควบคุมการปลอมหลายตัวตนของครอว์ลเลอร์ (Sybil attack) หรือการครอว์ลแบบขนาน
รูปแบบการเข้าถึงมีดังนี้:
ประเด็นคือป้องกันไม่ให้เซิร์ฟเวอร์โอเวอร์โหลดจากการเข้าถึงพร้อมกันมากเกินไป
ต่อให้ครอว์ลเลอร์ส่งคำขอขนานหลายชุด แต่ละคำขอก็จะมีต้นทุนและข้อจำกัดเพิ่มขึ้น ทำให้ไม่เกิดสถานการณ์ที่ทราฟฟิกบอตระดับหลายพันครั้งต่อวินาทีทำเซิร์ฟเวอร์ล่มเหมือนแต่ก่อน
นี่แหละคือผลลัพธ์จริงของ Anubis
แค่มีสคริปต์ที่ผ่าน Anubis แล้วแก้ challenge ได้ก็เลี่ยงได้แล้ว
เมื่อก่อนผมมองว่าวิธีเชิงกระบวนการแบบนี้นอกจากน่ารำคาญแล้ว ก็ยังน่าสงสัยว่าช่วยยืนยันคนจริงได้แค่ไหน
ความท้าทายพวกนี้ทำให้อัตโนมัติได้ง่ายและต้นทุนต่ำ
ผมถึงขั้นทำส่วนขยายเบราว์เซอร์ที่เอา "Mozilla" ออกจาก User Agent สำหรับเว็บที่รัน Anubis จริง ๆ
เพราะส่วนใหญ่ผมไม่ใช้ JS หรือคุกกี้ เลยผ่าน challenge ไม่ได้อยู่แล้ว และบางเว็บอย่าง self-hosted Gitlab ที่ยอมให้ JS กับคุกกี้ได้ ผมก็ไม่อยากให้ทรัพยากรเครื่องตัวเองถูกเอาไปใช้ขุด
ถ้าไปแตะ User Agent header คุณก็แทบจะสร้างตัวระบุเฉพาะของตัวเองขึ้นมาทันที ต้องระวัง
การทำ browser fingerprinting ได้ผลดีเป็นพิเศษกับผู้ใช้ที่มีค่า header แปลก ๆ
แค่ใช้ Safari แบบไม่ได้แก้ไขก็มีผู้ใช้นับล้านแชร์ค่าเดียวกัน แต่พอเปลี่ยน User Agent มันก็กลายเป็นตัวระบุเฉพาะทันที
ถ้าเว็บเป็นแบบ "sticky" ก็อดคิดไม่ได้ว่าอาจถึงขั้นขุดคริปโตอย่าง Monero อยู่เบื้องหลังจริง ๆ ก็ได้
อยากให้มีคำเตือนในเบราว์เซอร์ประมาณว่า “เว็บไซต์นี้กำลังใช้คอมพิวเตอร์ของคุณมากผิดปกติอยู่เบื้องหลัง ต้องการหยุดหรือไม่?”
มีคำถามเหมือนกันว่าถ้าเปลี่ยนค่า User Agent แล้วฟังก์ชันอื่น ๆ จะพังตามไปด้วยหรือเปล่า
สตริง User Agent ของเบราว์เซอร์ส่วนใหญ่ทุกวันนี้ก็เต็มไปด้วย “คำโกหก” มาตรฐานอยู่แล้ว เลยไม่ค่อยกล้าไปแตะมัน
รู้สึกสนใจส่วนขยายที่คุณทำขึ้นมา
ทำให้นึกอยากลองว่าจะบังคับเปลี่ยน text encoding ของหน้าเว็บเป็นภาษาญี่ปุ่นได้ไหม
ถ้าบอต AI ก็เปลี่ยน User Agent ได้เหมือนกัน สุดท้ายผลก็ไม่ต่างกันอยู่ดีไม่ใช่หรือ
สำหรับข้อถกเถียงว่า character ของ Anubis เป็นแมวหรือไม่ ชื่อ Anubis เองก็มาจากเทพเจ้าอียิปต์ที่โดยทั่วไปมักถูกวาดเป็นหมาในหรือสุนัข
ตามชื่อก็บอกอยู่แล้วว่าเป็นผู้เฝ้าประตูของโลกหลังความตาย
ถ้าจะพูดให้ตรงทางเทคนิค ก็ต้องเป็น “สาวหมา” หรือ “สาวหมาใน” มากกว่า
มีการแซวว่าทำให้รู้สึกโล่งใจขึ้นมาก
แต่ก็น่าเสียดายที่ลักษณะเด่นดั้งเดิมของ Anubis ในเชิงภาพหายไป
ผมคิดว่าผู้ให้บริการ AI ในทางปฏิบัติมีทรัพยากรประมวลผลอยู่ในดาต้าเซ็นเตอร์อยู่แล้ว ดังนั้นวิธีแบบ PoW จึงกลับกลายเป็นการจำกัดผู้ใช้ทั่วไปที่ทรัพยากรน้อยมากกว่า
แต่ในโลกความจริงดูเหมือน Anubis จะยังถูกยอมรับว่าเป็นทางเลือกที่แย่น้อยที่สุดซึ่งพอใช้งานได้
ถ้าทฤษฎีกับความจริงต่างกัน ก็อาจเป็นเพราะผมพลาดอะไรไป หรือไม่ก็ทฤษฎีผิดเอง
แค่เห็นหน้าจอ Anubis ก็จำได้ทันที และหวังว่าสาวแมวอนิเมะของโปรเจกต์นี้จะไม่หายไปไหน
ทุกวันนี้อินเทอร์เน็ตกลายเป็นโลกองค์กรและแห้งแล้งเกินไป การยังมีองค์ประกอบน่ารักแบบนี้หลงเหลืออยู่ทำให้รู้สึกดี
เนื่องจาก Anubis เดิมมาจากเทพเจ้าอียิปต์หัวสุนัข จึงมองภาพนี้แล้วคิดว่าเป็น “สาวหมา”
โปรเจกต์ที่ใช้ตัวละครอนิเมะเป็นมาสคอตไม่ได้มีแค่นี้
ComfyUI ก็ใช้ตัวละครสาวจิ้งจอกเป็นมาสคอตทางการเช่นกัน และมันก็เป็นมาตรฐานโดยพฤตินัยของ UI สร้างภาพบนฐาน Stable Diffusion
ถ้า AI scraper แค่ทำ PoW อย่างจริงจังหรือเพียงเอา ‘Mozilla’ ออกจาก User Agent ก็ทำให้มาตรการป้องกันนี้ไร้ความหมายได้ทันที ก็มีมุมมองว่าโปรเจกต์นี้อาจหายไปในไม่ช้า
สำหรับคำอธิบายที่ว่า “CAPTCHA คือการตั้งโจทย์ที่ยากสำหรับคอมพิวเตอร์แต่ง่ายสำหรับมนุษย์” ผมอดสงสัยไม่ได้ว่าเคยมีใครต้องแก้ CAPTCHA แบบ “เลือกช่องที่มีแรบไบสายออร์โธดอกซ์” แล้วคิดว่ามันง่ายจริงหรือเปล่า
เรื่องวุ่น ๆ กับแคปช่าของ RapidShare ในปี 2008 นั้นตลกดี
ลิงก์ที่เกี่ยวข้อง 1
ลิงก์ที่เกี่ยวข้อง 2
ลิงก์ที่เกี่ยวข้อง 3
มีคำตอบเชิงขำว่าถ้าเป็น CAPTCHA แบบนั้น วันเสาร์ก็แก้ไม่ได้เหมือนกัน
ทุกวันนี้ก็มีบริการรับแก้ CAPTCHA แทนในราคาถูกอยู่มาก
สำหรับทราฟฟิกมหาศาลของบริษัท AI อาจได้ส่วนลดเพิ่มด้วย และส่วนขยายเบราว์เซอร์อย่าง NopeCHA ก็สำเร็จราว 99% จนช่วยลดความเหนื่อยจากการต้องแก้เองได้
สุดท้ายแล้ว ต่อให้ใช้ CAPTCHA ที่ยาก ก็มีแต่ทำให้ลูกค้าจริงลำบากเท่านั้น
แน่นอนว่ากำลังพูดถึงกรณีที่ยังแก้ CAPTCHA ด้วย AI เองไม่ได้ แต่ทุกวันนี้ AI ก็ทำได้มากพอแล้ว
ท้ายที่สุดคอมพิวเตอร์ก็เก่งไปหมดทุกอย่าง
CAPTCHA ช่วงต้นยุค 2000 นั้นยากสำหรับคอมพิวเตอร์จริง ๆ
ผมคิดว่าสามารถใช้วิธีเก็บตัวระบุของ JWT token ที่ Anubis ออกระหว่างการทำงาน แล้วติดตามจำนวนหรือความเร็วของคำขอที่เกิดจากแต่ละโทเคน และถ้าเกิน threshold ที่กำหนดก็เพิกถอนโทเคนหรือใส่ delay response หรือจำกัดการใช้งานได้
ต่อให้บอตแก้ challenge ผ่านแล้ว ถ้ารักษาโทเคนไว้และส่งคำขอเร็วเกินไปก็จะโดนจำกัดทันที
ยังอาจคิดต่อได้ถึงวิธีจำกัดไม่ให้ออกหลายโทเคนจาก IP เดียวกัน
บางครั้งพอเห็นหน้าจอแบบ Anubis ก็อดกังวลไม่ได้ว่ามันอาจพาไปยัง redirect อันตรายหรือเว็บ imageboard แปลก ๆ
ก็แปลกใจเหมือนกันที่ kernel.org ใช้เวอร์ชันฟรีแบบมีอนิเมะแทนที่จะเป็นเวอร์ชันจ่ายเงินแบบไม่มีอนิเมะ
เลยมีมุกว่า Linux Foundation ขับ BMW กันหมดแล้วจนไม่มีเงินจริง ๆ หรือไง
เดี๋ยวนี้อนิเมะก็แมสขึ้นมากจน Netflix ทำรายได้ปีละหลายพันล้าน แต่ยังน่าทึ่งที่บางคนเห็นแค่ภาพอนิเมะใส ๆ แบบนี้แล้วกลับคิดไปไกล
จริง ๆ แล้ว Anubis ไม่ได้เป็นโปรเจกต์ต้นฉบับ แต่เป็นโคลนของ Kiwiflare ดังนั้นภาพลักษณ์แบบนั้นก็ไม่ถึงกับผิดทั้งหมด
ลิงก์เกี่ยวกับ Kiwiflare
ก็สงสัยว่าจำเป็นต้องมีเวอร์ชันไร้แบรนด์ด้วยหรือ
ซอฟต์แวร์โอเพนซอร์สมักแจกจ่ายง่ายกว่าอยู่แล้วเพราะไม่ต้องมีไลเซนส์แยกหรือหน้าดาวน์โหลดเฉพาะ
ถ้าเป็นโปรเจกต์ที่พึ่งพากันอยู่ ก็แค่บริจาคก็พอ ไม่จำเป็นต้อง debrand เสมอไป และถ้าไม่ได้มีเหตุผลต้องลบแบรนด์ แบรนด์เดิมกลับช่วยสร้างความน่าเชื่อถือได้ด้วย
เช่น ถ้าเห็นมาสคอต Anubis ก็อาจไว้ใจ JavaScript แล้วเปิดใช้งานมากขึ้น แต่ถ้าไร้แบรนด์ก็อาจนึกว่าเป็นโค้ดจากบริษัท CAPTCHA แปลก ๆ
ส่วน LKML นั้นแต่ไหนแต่ไรก็ไม่ค่อยสนใจงานออกแบบอยู่แล้ว เลยไม่ค่อยมีผลเท่าไร
วิธีพิสูจน์ความเป็นมนุษย์อย่างการให้ตอบคำถามที่คนเท่านั้นจะตอบง่าย หรือให้ช่วยนับบางอย่าง กลับใช้เป็นตัวกรอง LLM ได้ผลดีอย่างคาดไม่ถึงด้วย
เช่น มีฟอรัมที่ถามตอนสมัครให้นับจำนวนตัวอักษรของคีย์เวิร์ดบางคำ หรือถามเส้นผ่านศูนย์กลางของชิ้นส่วนรถยนต์ ซึ่งใช้งานจริงแล้วได้ผลดีมาก
ฟอรัมเล็ก ๆ ถ้าวางกลยุทธ์ขั้นตอนสมัครให้เหมาะ ก็ลดบัญชีสแปมได้มากจริง ๆ
เมื่อก่อนผมเคยเปลี่ยนฟอรัมที่มีสมัครสแปมเยอะ ให้กรอกตัวเลข 6 หลักแล้วบวก 1 เข้าไป ผลที่ได้ต่างอย่างมาก
เป็นวิธีที่พิสูจน์แล้ว
เมื่อก่อนในฟอรัมเกมชื่อ moparscape เขาจะถามว่า 'mopar คืออะไร' ซึ่งผมต้องไปค้นทุกครั้ง
แต่ก็ควรจำไว้ด้วยว่าคำถามแบบนี้เองก็มีผู้ใช้ทั่วไปบางส่วนที่ตอบได้ยากเหมือนกัน