3 điểm bởi GN⁺ 2025-04-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Anubis đã được triển khai trên policytoolbox.iiep.unesco.org của UNESCO, khiến công cụ đối phó bot này càng được chú ý hơn như một ví dụ được các tổ chức lớn sử dụng
  • Sau khi xác nhận unesco.org là tên miền chính thức của UNESCO, đợt triển khai này được xem là một trường hợp sử dụng thực tế của một tổ chức thuộc Liên Hợp Quốc
  • Công cụ này cũng đang được dùng cùng với các nơi triển khai đã được biết đến như kho lưu trữ Linux Kernel Mailing List, FreeBSD SVN, SourceHut, FFmpeg, Wine và GNOME GitLab, cho thấy phạm vi ứng dụng ngày càng rộng
  • Việc những tổ chức như vậy áp dụng Anubis cho thấy vấn đề lưu lượng bot trên internet có thể nghiêm trọng hơn dự đoán
  • Cần đầu tư thêm thời gian cho Anubis và hệ sinh thái xung quanh; nếu có đủ tài trợ, dự án thậm chí có thể phát triển toàn thời gian và tuyển dụng thêm

Xác nhận triển khai tại UNESCO

  • Anubis đã được triển khai trên policytoolbox.iiep.unesco.org của UNESCO, một tổ chức thuộc Liên Hợp Quốc
  • unesco.org được liệt kê trên Wikipedia là tên miền chính thức của United Nations Educational, Scientific and Cultural Organization
  • Tác giả dự định liên hệ với đội quản trị hệ thống của UNESCO để xác nhận liệu có vấn đề nào trong quá trình cài đặt hay không, đồng thời muốn đơn giản hóa quy trình cài đặt hơn nữa

Các trường hợp triển khai đã biết và công việc sắp tới

  • Các trường hợp triển khai quy mô lớn đã được xác nhận gồm có
    • kho lưu trữ Linux Kernel Mailing List
    • SVN của FreeBSD, sắp tới là git
    • SourceHut
    • FFmpeg
    • Wine
    • UNESCO
    • The Science Olympiad Student Center
    • môi trường desktop Enlightenment
    • GitLab của GNOME
  • Nếu những tổ chức ở quy mô này đang sử dụng Anubis, thì vấn đề lưu lượng bot có thể nghiêm trọng hơn nhiều so với dự đoán trước đây
  • Tương tự như trường hợp YouTube từng tiến gần tới “the inversion”, khi lưu lượng bot vượt lưu lượng con người, câu hỏi còn lại là hiện tượng tương tự đã lan rộng đến mức nào trên toàn bộ internet
  • Cần dành thời gian nghiêm túc hơn cho Anubis và stack liên quan; nếu đảm bảo được đủ tài trợ, dự án có thể được thực hiện toàn thời gian và thậm chí tuyển dụng thêm người
  • Nếu Anubis hữu ích với bạn, tác giả kêu gọi ủng hộ qua Patreon

1 bình luận

 
GN⁺ 2025-04-14
Các ý kiến trên Hacker News
  • Bài liên quan: Anubis: Proxy proof-of-work để chặn crawler AI (100 points, 23 ngày trước, 58 comments) https://news.ycombinator.com/item?id=43427679

  • Thú vị là Xe đã biến thứ trước đây gần như chỉ là trò đùa/bài viết nhảm thành một sản phẩm thực sự hữu ích. Vẫn thường nói thời điểm là tất cả
    Việc nhiều site muốn hoặc cần thứ này đến vậy hơi đáng ngạc nhiên. Tôi hiểu vấn đề các trang Git chậm trên một số Git server rất sâu, không có cache, phục vụ từ đĩa chậm
    UNESCO thì hơi bất ngờ. Subsite đó khá lớn với hàng nghìn tài liệu, nhưng là nội dung tĩnh nên lẽ ra phải dễ phục vụ. Xem qua thì đó là WordPress được triển khai cẩu thả trên Apache, không cache, không nén nội dung, cũng không có HTTP/2·HTTP/3
    Có khả năng khá dễ sửa để phục vụ với chi phí rất rẻ ngay cả trên một máy rất nhỏ, nhưng tất nhiên vẫn cần chuyên môn, mà chuyên môn thì vẫn không rẻ
    Có thể hỏi LLM, nhưng nếu bạn còn không biết phải hỏi gì thì hiện giờ nó vẫn chưa giúp được nhiều. Nếu bạn thậm chí không biết site vốn đã chậm, tại sao lại hỏi? Có lẽ bạn chỉ nghe nói nó bị traffic đè bẹp rồi đi tìm một vệ sĩ furry

    • “Cần chuyên môn và chuyên môn vẫn không rẻ” là đúng, nhưng đồng thời tôi nghĩ người biết cấu hình Anubis còn ít hơn rất nhiều so với người có kinh nghiệm quản trị WordPress, nên vẫn thấy ngạc nhiên
      Không phải nói là khó, mà là ngay cả số người biết nó tồn tại cũng đã ít
      Tôi đoán lý do không đụng vào WordPress không phải vấn đề kỹ thuật, mà có thể là không muốn chạm vào một instance mong manh dễ vỡ, hoặc vấn đề quyền hạn trong tổ chức, hoặc quản trị viên mặc định cho rằng WP đã được cấu hình tốt
    • Site của tôi mà tôi muốn áp dụng thứ này có nhiều bài viết, và nhờ tìm kiếm phân diện dựa trên tag nên số tổ hợp và số trang khả dĩ gần như vô hạn
      Không có cách nào cache được việc này, và bot thì không tuân thủ file robots, cứ tiếp tục yêu cầu URL rồi lấy bài viết lặp đi lặp lại theo nhiều con số và tổ hợp khác nhau. Thật sự rất đau đầu
    • AI scraper không chỉ được triển khai cẩu thả mà còn cố tình vô hiệu hóa cache
      Những giải pháp tôi thấy đến giờ chỉ có Cloudflare, yêu cầu đăng nhập, Anubis, hoặc hạ tầng ở quy mô phi lý
      Có site nói 60% traffic của họ đến từ bot, còn các site nhỏ hơn có lẽ tỷ lệ đó còn cao hơn nhiều
    • Phòng thủ bot/scraping/DDoS dựa trên proof-of-work đã có từ 10 năm trước rồi, không hiểu sao bây giờ mới lan rộng
      Tôi cũng nhớ có dự án từng cố biến proof-of-work thành các phép tính hữu ích
  • Nếu bạn đang bối rối không biết đây là gì, thì nó là để chặn AI scraping
    “Anubis dùng các bài toán proof-of-work để bảo đảm client đang dùng trình duyệt hiện đại và có thể tính checksum SHA-256”
    https://anubis.techaro.lol/docs/design/how-anubis-works
    Khá hay, và có thể giúp ích cho một hai dự án của tôi

    • Từ vài năm trước tôi đã tự hỏi web là dành cho con người hay dành cho máy móc. Tôi không nghĩ ra được lý do tốt nào để phải đặc biệt chặn bot trong việc phục vụ nội dung
      Việc cho phép đăng nội dung hoặc thực thi tác vụ thì đương nhiên có thể là vấn đề trong nhiều tình huống
      Nhưng với việc chỉ phục vụ nội dung đơn thuần, thường thì việc là người hay bot không phải tiêu chí để lọc hoặc chặn. Nếu một client cụ thể không lạm dụng hệ thống, tại sao phải quan tâm client đó có phải con người hay không?
  • “Ngoài ra, thời gian cũng được dùng làm input. Vì do đặc tính của dòng thời gian tuyến tính, cả server lẫn người yêu cầu đều biết thời gian là gì”
    Đây là một câu buồn cười trong tài liệu

    • Trời, tôi quên mất mình đã để câu đó lại. Buồn cười thật. Tôi định cứ giữ nguyên
    • Đáng tiếc là nếu tách khỏi ngữ cảnh thì câu này sai. Anubis làm tròn thời gian đến tuần gần nhất, và nếu tuần liền kề cũng hợp lệ thì có lẽ đủ dùng
      Vì nhiều lý do, lệch đồng bộ đồng hồ là chuyện phổ biến. Không thể kỳ vọng 10% người dùng thấp nhất chính xác đến mức theo ngày, và ngay cả 25% thấp nhất cũng có thể lệch khoảng 5 phút
  • Các hình ảnh trang trung gian hiện trong lúc chờ kiểm tra Anubis kết thúc thật sự dễ thương. Tôi luôn thấy tranh và nhân vật trên blog của Xe rất đẹp
    Nhân tiện, tôi cũng tò mò chuyện này sẽ ảnh hưởng thế nào đến các công cụ tìm kiếm thông thường, và khác gì với giải pháp của Cloudflare để chặn crawler AI; trên trang GitHub có giải thích [1]
    “Nếu cài đặt và dùng thứ này, nhiều khả năng một số công cụ tìm kiếm sẽ không lập chỉ mục website của bạn. Đây được xem là tính năng của Anubis, không phải lỗi”
    “Đây là một phản ứng hơi kiểu tấn công hạt nhân, nhưng bot AI scraper đã cào dữ liệu quá hung hăng nên không còn cách nào khác”
    “Trong hầu hết trường hợp bạn không cần dùng thứ này, và có lẽ chỉ cần dùng Cloudflare để bảo vệ một origin server cụ thể là đủ. Nhưng trong trường hợp không thể hoặc không muốn dùng Cloudflare, thì đã có Anubis”
    [1]: https://github.com/TecharoHQ/anubis/

    • Đúng vậy. Ở thời điểm hiện tại, đáng tiếc là nó chặn lập chỉ mục tìm kiếm. Sau này có thể sẽ cho phép đưa IP của công cụ tìm kiếm vào allowlist
      Tuy nhiên những nơi như Google đôi khi dùng cùng IP cho AI và lập chỉ mục tìm kiếm
      Dù vậy, vẫn đang cải thiện, chẳng hạn cho các thẻ Open Graph đi qua, để ít nhất rich preview có thể hoạt động
    • Tôi đồng ý là các hình ảnh trang trung gian rất dễ thương. Nhưng nghĩ đến việc một ngày nào đó ai đó sẽ đánh giá chúng là “có vấn đề” theo cách nào đó rồi cuối cùng chúng bị gỡ bỏ thì thật kinh khủng
  • Tôi đã đọc về Anubis và thấy đây là một dự án rất hay. Tiếc là như trong phần bình luận đã nói, khách truy cập trang phải bật JavaScript™
    Nếu dù sao trang cũng cần JavaScript™ để cải thiện trải nghiệm người dùng thì hoàn toàn ổn, nhưng với những nơi như site tĩnh vốn không cần JS chút nào thì không hay lắm
    Tôi đã tự xây một giải pháp chặn hiệu quả các “bot xấu” này ở cấp mạng. Dùng cơ sở dữ liệu MaxMind cùng WAF và reverse proxy tự làm, tôi đang chặn toàn bộ nhiều mạng “Big Tech / Big LLM” lớn theo ASN (BGP)

    • Một phần đáng kể lưu lượng bot mà bài này muốn xử lý đến từ dải IP hộ gia đình thông thường
      Tất nhiên cũng có trò gian lận ASN và lừa đảo uy tín mạng, nhưng rất khó đối phó. Điều tra sơ bộ log cho thấy các bot này chỉ gửi khoảng một request từ một IP hộ gia đình nhất định, và dải đó nhiều khả năng cũng là dải người dùng thật đang dùng
      Nói ngắn gọn là có nguy cơ chặn nhầm lưu lượng hợp lệ. Giải pháp này cũng có rủi ro, nhưng rủi ro thực tế với đa số người dùng thật thấp hơn nhiều
      Sẽ tốt nếu không cần JavaScript và vẫn hỗ trợ được người dùng đã tắt nó, nhưng chưa từng có khách hàng hay người dùng cuối nào phàn nàn về việc cần bật JavaScript
      Phản đối yêu cầu JavaScript chỉ là một thiểu số ồn ào, và phần lớn trong số họ khi gặp site cần JavaScript thì cũng chỉ bật lên. Ngay cả lúc đó, tôi nghĩ số người thở dài chịu thua cũng cực kỳ ít
    • Dành cho ai tò mò, nhãn hiệu “JavaScript” thuộc sở hữu của Oracle: https://javascript.tm/
    • Làm sao biết đó là LLM hay VPN? Làm thế nào dùng cơ sở dữ liệu MaxMind để tách lưu lượng LLM?
    • Có link đến giải pháp tự làm đó không?
  • Tôi thích ý tưởng này, nhưng khi bản chất của bài toán được định hình rõ hơn thì có lẽ nó nên được đưa xuống cấp giao thức
    Xét về khả năng tiếp cận, cuối cùng sẽ tốt hơn nếu bài toán proof-of-work trở thành một phần gần với TCP, thay vì được từng website triển khai riêng bằng JavaScript

    • Có Cloudflare PrivacyPass đã thành chuẩn IETF [0], nhưng nó khá kỳ lạ và bản triển khai tham chiếu thì là một đống bug
      [0] https://datatracker.ietf.org/wg/privacypass/about/
    • Chỉ cần gửi một bài toán tùy ý vào một hộp đen SPIR-V hoặc MLIR là được. Nếu tích hợp trao đổi thử thách-phản hồi với HTTP, có thể đạt được hỗ trợ rộng rãi và tăng tốc phần cứng linh hoạt
      Một giải pháp “đủ tốt” là SHA(seed, nonce) vốn đã được dùng rộng rãi. Nếu các ông lớn công nghệ muốn, chuyện này đã có thể dễ dàng được tích hợp vào các tầng thấp hơn của stack
  • Trên điện thoại của tôi, việc giải bài toán phát hiện bot mất tận 5 giây

    • Tôi dùng Fennec, bản fork Firefox trên F-Droid, với Pixel 9 Pro XL, và ở độ khó 4 mất khoảng 8 giây
      Cá nhân tôi không thấy trải nghiệm người dùng tệ lắm vì không phải làm gì cả. Chắc chắn tôi thích nó hơn CAPTCHA
    • Tốt hơn nhiều so với vòng lặp CAPTCHA Cloudflare vô tận
    • May đấy. Tôi mất 30 giây
    • Trường hợp của tôi khoảng 0,5 giây nên khá thú vị
  • Hiện tôi đang làm một prototype gọi là “phông web Enigma”. Tôi muốn áp dụng seed và giá trị xoay tùy chỉnh theo từng phiên người dùng cho webfont được cung cấp và cache
    Mục tiêu là khiến web scraping trở nên phi thực tế vì chi phí tính toán OCR. Hiện giờ đây là trò mèo vờn chuột, nên tôi muốn thay đổi cục diện một chút
    Nếu không có phiên người dùng, mã nguồn HTML về cơ bản sẽ trở nên vô nghĩa; và nếu cache tài nguyên biến mất theo cách hoạt động kiểu OTP, trang web cũng sẽ không thể đọc được
    Như vậy có thể tạo CAPTCHA một cách hiệu quả, trong đó người dùng điều chỉnh cửa sổ seed cục bộ cho đến khi đọc được một từ nhất định. Ví dụ kiểu “hãy di chuyển thanh trượt cho đến khi đọc được từ Foxtrott”
    Tôi rất muốn nghe ý kiến của Xe. Liệu chúng ta có thể hợp tác không?
    Stack công nghệ là Go, vì đó là ngôn ngữ duy nhất giúp tôi dễ dàng tự sửa trực tiếp file webfont mà không gặp vấn đề

    • Ngay cả bỏ qua vấn đề accessibility hiển nhiên, cùng lắm đó chẳng phải chỉ là một dạng mã thay thế sao? Nếu có đủ corpus thì việc phá mã có vẻ sẽ dễ hơn nhiều
    • Vấn đề không phải là bản thân website bị scrape, mà là lượng request làm sập hạ tầng hoặc tăng chi phí. Các công cụ tìm kiếm đã làm chuyện này hơn 30 năm rồi
      Làm hỏng văn bản cũng sẽ không giúp gì. Dù sao chúng vẫn sẽ tiếp tục bắn request. Nhìn vào mẫu lưu lượng thì người tạo ra các bot này chỉ là... <https://www.youtube.com/watch?v=ulIOrQasR18>
      Về câu “muốn nghe ý kiến của Xe. Liệu chúng ta có thể hợp tác không?”, theo những gì tôi hiểu thì dự án này cần được giúp để trở nên bền vững hơn trong tương lai gần và xa, hơn là nhồi thêm tính năng. Anubis có vẻ đã hoạt động rất tốt rồi
  • Đúng là nó hoạt động tốt trong việc chặn người dùng đã tắt JavaScript

    • Đúng. Nếu đây là nỗ lực để khiến nó hấp dẫn hơn với nhiều người hơn thì thật sự quá yếu. Trừ khi đưa ra phiên bản nojs, nó chẳng khác gì các scraper “AI” ở chỗ làm hỏng web