Anubis thực sự chặn ai?

 (fzakaria.com)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Anubis, công cụ yêu cầu Proof-of-Work trước khi cho phép truy cập HTTP, trên thực tế lại áp đặt chi phí dai dẳng lớn hơn lên người dùng bình thường, thiết bị cấu hình thấp và các client không hỗ trợ JavaScript hơn là các AI scraper
  • anubis-fetch do LLM tạo ra có thể tự giải bài toán Proof-of-Work, chạy Chromium khi cần, và mô phỏng dấu vân tay TLS/JA3 của Chrome để vượt qua cả chặn thủ công của Cloudflare
  • Scraper có thể cache và tái sử dụng cookie đã được cấp để phân bổ chi phí qua nhiều yêu cầu, trong khi con người phải chấp nhận chờ vài giây và tiêu hao pin mỗi lần truy cập
  • Độ khó mặc định 4 yêu cầu trung bình 65.536 lần băm; bản triển khai Go native mất khoảng 1,3ms, JavaScript trên trình duyệt mất khoảng 130ms, nhưng thời gian chờ mà người dùng thực sự cảm nhận vào khoảng 1–5 giây
  • Nếu giả định thời gian cảm nhận là 2 giây và năng lượng 20J cho mỗi lần, thì 1 triệu thử thách mỗi ngày sẽ tiêu tốn khoảng 23 người-năm·2MWh mỗi năm, còn 100 triệu mỗi ngày sẽ tiêu tốn khoảng 2.300 người-năm·200MWh

AI đã vượt qua Anubis

  • Trong lúc thực hiện bản vá để hỗ trợ $ORIGIN trong PT_INTERP của trình thông dịch thông qua bpf của binfmt_misc trong nhân Linux, tác giả đã yêu cầu LLM đọc chuỗi thảo luận trên mailing list của nhân Linux
  • lore.kernel.org khi đó đã triển khai Anubis, một proxy HTTP yêu cầu Proof-of-Work trước khi cho phép truy cập tài nguyên
  • LLM đã tạo ra anubis-fetch để xử lý hạn chế này
    • Trước tiên, nó giải Proof-of-Work theo cách native; nếu thất bại thì truy cập URL bằng Chromium
    • Nó dùng req để mô phỏng dấu vân tay TLS/JA3 của Chrome thật, nhờ đó vượt qua cả chặn thủ công của Cloudflare
    • anubis-fetch <URL> xuất HTML ra standard output, còn tùy chọn --text xuất văn bản thuần dễ đọc
  • AI và bot mà Anubis nhắm tới có thể dễ dàng vượt qua chỉ bằng cách bổ sung một lần hỗ trợ Proof-of-Work
    • Sau khi giải thử thách, scraper có thể cache và tái sử dụng cookie nhận được để phân bổ chi phí qua nhiều yêu cầu
    • Ngược lại, con người phải chờ spinner và tiêu hao pin mỗi lần truy cập, và không thể chia sẻ chi phí này với người dùng khác
    • Thiết bị cấu hình thấp và smartphone càng chịu gánh nặng lớn hơn, còn các công cụ không dùng JavaScript như w3m·lynx·trình đọc màn hình·trình đọc RSS thì không thể truy cập
  • Một cơ chế nhằm chặn AI lại dễ dàng bị AI vượt qua, trong khi tiếp tục áp đặt gánh nặng lũy thoái lên con người và web mở

Chi phí thời gian và năng lượng do Proof-of-Work tạo ra

  • Độ khó d là số ký tự hexa số 0 ở đầu mà giá trị băm phải có, và lượng công việc kỳ vọng cho mỗi lần giải là W = 16^d lần băm
    • Độ khó 4, giá trị mặc định phổ biến, yêu cầu 65.536 lần băm
      • Bản triển khai Go native khoảng 50 MH/s: khoảng 1,3ms
      • JavaScript trên trình duyệt khoảng 0,5 MH/s: khoảng 130ms
      • Thời gian cảm nhận, bao gồm tải trang, chạy worker và tải lại: khoảng 1–5 giây
    • Độ khó 5 yêu cầu 1.048.576 lần băm
      • Bản triển khai Go native: khoảng 20ms
      • JavaScript trên trình duyệt: khoảng 2 giây
      • Thời gian cảm nhận: khoảng 5–15 giây
  • Giả sử số lần giải thử thách Anubis mỗi ngày trên toàn thế giới là C, thời gian cảm nhận mỗi lần là t = 2초, và năng lượng thiết bị gồm màn hình và CPU là E = 20J
    • Thời gian của con người trong một năm được tính bằng C × t × 365 / 3.15×10⁷
    • Năng lượng hằng năm được tính bằng C × E × 365 / 3.6×10⁶kWh
  • Theo các giả định này, chi phí hằng năm như sau
    • 1 triệu lần mỗi ngày: khoảng 23 người-năm, khoảng 2MWh
    • 10 triệu lần mỗi ngày: khoảng 230 người-năm, khoảng 20MWh
    • 100 triệu lần mỗi ngày: khoảng 2.300 người-năm, khoảng 200MWh
  • Mọi con số đều chỉ là ước tính gần đúng; bot farm và công cụ AI tiêu thụ năng lượng lớn hơn nhiều bậc độ lớn, nên đây không phải phép tính nhằm lập luận về vấn đề môi trường
  • Với robot, thời gian không phải ràng buộc, nhưng thời gian của con người là hữu hạn; vì vậy người dùng đang phải collectively dành một lượng thời gian đáng kể để chờ truy cập website, điều vốn không tồn tại trước kỷ nguyên AI

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Các ý kiến trên Lobste.rs

  • Khó đồng ý với nhận định rằng đối tượng mà Anubis nhắm tới có thể dễ dàng vô hiệu hóa nó. Mục tiêu chính của Anubis không phải là các LLM agent hay chương trình được tạo bằng vibe coding, mà là chặn các trình thu thập web kiểu vét cạn mà các công ty LLM sử dụng.
    Có cách обход và cũng có thể tận dụng agent hoặc LLM, nhưng phần lớn scraper rất đơn giản, và người vận hành cũng không muốn mất công обход một số ít trang đã áp dụng Anubis. Mục đích đúng hơn là nâng chi phí обход lên một chút để khiến việc thu thập không còn đáng làm.

    • Anubis có lẽ sẽ hoạt động tốt trong việc ngăn tình huống scraper dùng proxy dân cư làm tê liệt máy chủ. Các yêu cầu từ từng agent riêng lẻ không khác nhiều so với việc người dùng tự duyệt trang.
      Tuy nhiên, với mục đích này thì Anubis đã được thiết kế quá mức. Chỉ cần bắt bấm một nút rồi cấp cookie truy cập cũng có thể đạt cùng hiệu quả bảo vệ; tôi đã thử triển khai trên Apache và thấy nó hoạt động đủ tốt mà không cần proof-of-work phức tạp.
    • Đối tượng không hẳn là scraper của các công ty LLM, mà là toàn bộ các web scraper thô sơ và lạm dụng. Chỉ có suy đoán rằng một phần trong số đó do các công ty LLM vận hành.
    • Lưu lượng tăng trên website không đến từ OpenAI, Anthropic, Meta hay những nơi tương tự, mà từ các chủ thể khác, nên không rõ định nghĩa “công ty LLM” là gì.
      Các công cụ scraping hiện đại mà tôi cũng dùng trong công việc khai phá dữ liệu đủ tốt để vượt qua gần như mọi chướng ngại, và Anubis cũng có thể bị обход dễ dàng.
    • Tôi cũng muốn chặn truy cập RAG vào trang cá nhân và phần mềm của mình, nên đã áp dụng chặn user-agent cơ bản. Tôi thử yêu cầu ChatGPT truy cập trực tiếp trang và thấy nó bị chặn tốt.
      Một số cấu hình rất đặc biệt có thể lọt qua, nhưng mục tiêu là chặn đối thủ lười biếng chứ không phải đối thủ ác ý.
    • Thứ Anubis chủ yếu chặn là các scraper Python requests sơ đẳng giả vờ làm Chrome một cách vụng về; các hiệu quả chặn khác gần như chỉ là phần thêm.

  • Anubis không lọc bot, mà giới hạn tốc độ yêu cầu của client.

  • Anubis giống một biện pháp phòng thủ chống tấn công từ chối dịch vụ hơn là chặn truy cập của AI agent, và trên thực tế cũng khó phân biệt rồi chặn AI agent.
    Nhưng nó cũng chặn luôn những người dùng như tôi, người truy cập một trang lạ trên thiết bị di động và tắt JavaScript.

  • Nhìn vào kết quả vận hành thực tế thì khó đồng ý với kết luận của bài viết. Tôi phục vụ website homelab qua proxy công khai fly.io và chuyển tiếp Tailscale, và các scraper, trong đó có Facebook, đã gây ra khoảng 20 USD phí băng thông mỗi tháng.
    Sau khi áp dụng Anubis cho proxy, tôi quay lại được mức miễn phí. Việc có thể bị обход nếu người ta thật sự muốn cũng không sao; chỉ cần chặn phần lớn lưu lượng thu thập hàng loạt từ một số ít chủ thể xấu phớt lờ robots.txt là đủ.

  • Với các hoạt động scraping tận dụng botnet trên thiết bị cấu hình thấp như smart TV, proof-of-work của Anubis có vẻ có thể trở thành trở ngại thực sự. Vấn đề này cũng được đề cập đôi chút ở https://lobste.rs/s/kpaxih/update_on_scraper_situation

    • Nếu tôi không hiểu sai thì smart TV chỉ được dùng làm proxy, chứ không tự thực hiện proof-of-work.

  • Phần khiến tôi bận tâm nhất ở Anubis là xung đột với web mở. Website của tôi chủ yếu được tiêu thụ qua RSS feed; nếu bảo vệ RSS bằng Anubis thì feed không hoạt động, còn nếu không bảo vệ thì toàn bộ nội dung bị phơi ra cho scraper ở dạng dễ đọc bằng máy.
    Những rào cản proof-of-work như thế về cơ bản khó tương thích với web mở hay IndieWeb mà chúng ta từng hướng tới.

    • Suốt một năm qua tôi đã bị kẹt giữa những thỏa hiệp bất khả thi như vậy, và chính tôi cũng chưa tìm được câu trả lời tốt.

  • Thái độ không tôn trọng lựa chọn của người khác thể hiện rất rõ.

  • Điều khó chịu nhất là việc này trông như hành vi rõ ràng vi phạm các luật như CFAA, vậy mà họ lại che giấu danh tính giống các dịch vụ DDoS phạm pháp khác.
    Thật nực cười khi kỳ vọng một công ty có toàn bộ mô hình kinh doanh dựa vào việc đánh cắp thành quả của người khác và “rửa” mã nguồn mở sẽ tuân thủ pháp luật.

  • Anubis thường không chặn Dillo, nhưng tùy cấu hình trang mà cũng có thể bị chặn, và điều đó cổ xúy bầu không khí rằng nếu không có JavaScript thì không đáng tồn tại, rất phiền phức: https://paste.rs/jNgwd.png
    Tôi đang cân nhắc liệu có thể thu thập và quản lý danh sách mọi IP nằm trong proxy dân cư rồi chặn trong một khoảng thời gian hay không; ipset có thể chịu được quy mô này. Nhìn log thì bot không tải các tài nguyên khác như CSS hay hình ảnh, nhưng lại duyệt qua mọi file trong mọi commit của kho Dillo, nên tương đối dễ nhận diện.
    Trên từng trang, dù chỉ thấy một yêu cầu từ mỗi IP, cùng IP đó rất có khả năng đang tải nhiều trang khác, nên có thể chặn các IP bị báo cáo nhiều lần. Không nên chỉ đơn giản cắt kết nối, mà nên chuyển hướng sang một trang hướng dẫn ở cổng riêng để cho biết lý do bị chặn và cách khắc phục.
    Làm vậy cũng giảm động cơ cài backdoor reverse proxy vào tiện ích trình duyệt hoặc ứng dụng điện thoại, vì người dùng sẽ bắt đầu thực sự bị chặn.
    Thật đáng tiếc khi phải dựa vào hệ thống uy tín IP, nhưng tôi không thấy nhiều biện pháp đối phó hiệu quả khác. Thiết bị dễ tổn thương, dù máy chủ chỉ huy-điều khiển của botnet bị gỡ bỏ, vẫn có thể lại bị kẻ tấn công tiếp theo chiếm và đưa vào botnet mới.

  • Trong bài có câu “tất nhiên tôi đang làm việc này với sự trợ giúp của LLM”, vậy tôi thắc mắc vì sao lại không gắn thẻ vibe coding.

    • Vì chủ đề của bài này không phải vibe coding, cũng như tác giả có dùng trình biên dịch hay trình soạn thảo thì cũng không gắn thẻ tương ứng. Thẻ vibecoding đã bị pushcx gỡ bỏ.
    • Khi đăng, trong bài có nêu rõ rằng tác giả đã vibe-code một thứ gì đó để vượt qua chặn, nên tôi đã gắn thẻ đó. Tôi thấy lạ khi nó bị xóa vì nhiều bài còn nhắc đến AI coding ít hơn thế cũng hay được gắn thẻ, nhưng tôi đã chấp nhận rằng tiêu chí áp dụng thẻ này hoàn toàn không nhất quán.