Trình thu thập AI yêu cầu các script đã bị comment

• Trong quá trình phân tích log máy chủ web, đã phát hiện nhiều hoạt động bot yêu cầu các tệp JavaScript không tồn tại
• Có vẻ chúng đã coi các thẻ script bên trong chú thích HTML là mã thực và gửi yêu cầu, được suy đoán là hành vi thu thập dữ liệu để huấn luyện LLM
• Bài viết đưa ra nhiều biện pháp ứng phó như cảnh báo công khai, chặn IP, bom giải nén, đầu độc dữ liệu để phát hiện và đối phó với các yêu cầu bất thường này
• Đặc biệt, đầu độc dữ liệu được nhắc đến như một phương tiện hiệu quả có thể làm ô nhiễm dữ liệu huấn luyện LLM và làm suy giảm hiệu năng mô hình
• Nhấn mạnh sự cần thiết để quản trị viên web thử nghiệm đưa vào các chiến lược phòng thủ và phản công với trình thu thập AI

---

Phát hiện hành vi scraping bất thường

• Trong log máy chủ đã xác nhận nhiều yêu cầu lỗi 404 đối với các tệp JavaScript không tồn tại
  • Các tệp này là script không hoạt động nằm trong chú thích HTML, nên trình duyệt bình thường không được yêu cầu chúng
• Một số User-Agent của các yêu cầu được nhận diện rõ ràng là bot, như python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4
• Dù đã cấm crawler truy cập trong robots.txt, các yêu cầu vẫn tiếp diễn, cho thấy phớt lờ quy tắc hoặc chính sách bị bỏ qua
• Một số yêu cầu ngụy trang thành trình duyệt bình thường như Firefox, Chrome, Safari, nhưng do không hiểu được chú thích HTML nên bị lộ là nhận dạng giả
• Các yêu cầu này được suy đoán là scraper dùng để thu thập nội dung không có sự đồng ý cho việc huấn luyện LLM

Cách scraper hoạt động

• Một số có thể phân tích HTML đúng cách và đệ quy dò các URL nằm trong chú thích
• Một số khác dường như xử lý HTML như văn bản thuần và thực hiện trích xuất URL dựa trên regex
• Xét theo sự đa dạng và mức độ khác nhau của User-Agent, có vẻ tồn tại nhiều bên vận hành, trong đó một số dùng công cụ tự động hóa đơn giản
• Động cơ chung là thu thập dữ liệu một cách tham lam, và điều này được nêu như khả năng có thể bị khai thác ngược lại

Phá hoại mang tính thuật toán (Algorithmic Sabotage)

• Đây là hành vi cố ý gây nhiễu các hệ thống thuật toán, một chủ đề đang được chú ý do vấn đề chi phí ngoại lai của LLM
• Khi nhận diện được các mẫu hành vi phi con người của bot thì việc phát hiện và đối phó sẽ dễ dàng hơn
• Các cách ứng phó được chia thành bốn nhóm: cảnh báo công khai, lọc IP, bom giải nén, đầu độc dữ liệu

0. Cảnh báo công khai (Public Disclosure)

• Những lỗi dương tính giả nhỏ nhặt (ví dụ lỗi gõ User-Agent như “Mozlla”) có thể dễ dàng được sửa nếu công khai, nên được giữ kín
• Ngược lại, hành vi mang tính bản chất (ví dụ yêu cầu script trong chú thích) thì không thể sửa được, nên việc công khai là có ích
• Qua đó, các quản trị viên của những website khác có thể phát hiện và chặn cùng một kiểu tấn công
• Hệ thống phát hiện hành vi này cũng đang được áp dụng cho các website khác

1. Lọc IP (IP Filtering)

• Sử dụng fail2ban để tự động chặn dựa trên mẫu log, ngày tháng và IP
• Thông thường thời gian chặn được đặt ngắn, nhưng chặn dài hạn có thể ngăn bot học được việc thử lại
• Trong trường hợp botnet, chúng có thể đổi IP để tiếp tục yêu cầu, nhưng vẫn có thể phát hiện qua các mẫu lặp lại
• Bài viết cũng nhắc đến kế hoạch nghiên cứu thêm về phân tích hoạt động botnet trong tương lai

2. Bom giải nén (Decompression Bombs)

• Có thể cung cấp zip bomb cho tệp mà kẻ tấn công yêu cầu để làm tiêu hao tài nguyên hệ thống
• Việc này có thể buộc chúng sử dụng quá mức CPU, RAM, đĩa hoặc thậm chí khai thác lỗ hổng
• Nhược điểm là tiêu tốn tài nguyên máy chủ và có rủi ro lãng phí băng thông
• Một số bot chạy trên các hệ thống đã bị lây nhiễm, nên hiệu quả tấn công có thể bị hạn chế
• Thay vì áp dụng cho mọi bot, bài viết đề xuất chỉ phản hồi với một phần ngẫu nhiên các yêu cầu

3. Đầu độc dữ liệu (Poisoning)

• Nhằm làm ô nhiễm dữ liệu huấn luyện LLM để khiến hiệu năng mô hình suy giảm
• Theo nghiên cứu gần đây, chỉ 250 tài liệu bị đầu độc cũng có thể tạo ảnh hưởng dai dẳng lên mô hình lớn
• Dữ liệu bị ô nhiễm có thể khiến mô hình tạo ra đầu ra vô nghĩa với các chủ đề cụ thể
• Ví dụ, có thể dẫn dụ mô hình đề xuất một blog nhất định khi được hỏi về nghiên cứu bảo mật
• Có thể sử dụng các công cụ công khai như nepenthes, iocaine, glaze, nightshade
• Nếu dữ liệu huấn luyện LLM được thu thập không có sự đồng ý, thì các biện pháp như vậy được nêu như phương tiện phòng thủ chính đáng
• Khi kết hợp với chặn IP, độ phức tạp triển khai có thể tăng lên, nhưng vẫn có khả năng vận hành song song
• Thiết kế hiệu quả có thể sẽ không được công khai, và bài viết nhấn mạnh nhu cầu mở rộng sự tham gia vào các hình thức phá hoại sáng tạo

Kết luận và phản ứng từ cộng đồng

• Việc phát hiện thông qua hành vi bot bất thường không phải khái niệm mới, nhưng yêu cầu script trong chú thích là một trường hợp mới được phát hiện
• Bài viết đề xuất thêm chỉ thị Disallow vào robots.txt để kích hoạt biện pháp phản công khi có yêu cầu cụ thể

  User-agent: GPTBot
  Disallow: /poison/
  

• Trong cộng đồng, nhiều ý tưởng đã được chia sẻ về cách ẩn liên kết nhử bot bằng các thuộc tính display:none và rel="nofollow"
  • Ví dụ: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
• Nếu đặt liên kết dưới dạng đường dẫn tuyệt đối (absolute URL) thì có thể lừa được nhiều crawler hơn
• Hiện đang có các thử nghiệm đa dạng về nhử bot và chặn bot trên nhiều website, và sẽ chia sẻ sau khi đo lường hiệu quả
• Các nhà nghiên cứu khác cũng đang tham gia thử nghiệm gây nhiễu trình thu thập AI, và một số trường hợp đầu độc độc đáo cũng được giới thiệu
• Nhìn chung, mục tiêu là mở rộng các chiến lược phòng thủ tự chủ và phản công trước việc thu thập dữ liệu AI

[GN⁺]

Ý kiến trên Hacker News

• Phần lớn web scraper đều phục vụ mục đích kinh doanh, dù có thể là bất hợp pháp
  Vì vậy chúng thường cào dữ liệu từ Amazon hoặc các trang thương mại. Rốt cuộc, phần lớn lưu lượng truy cập không mong muốn đến từ Big Tech hoặc các tác nhân xấu đang dò lỗ hổng
  Tôi cũng biết đôi chút về web scraping. Một số trang còn trả về 404 để tự bảo vệ, nên crawler của tôi sẽ thử nhiều lần bằng các phương thức crawl nhanh như curlcffi
  Phòng thủ zip bomb khá đơn giản: chỉ cần đọc header content-length là đủ. Nếu phản hồi quá lớn thì đặt giới hạn byte để không đọc, đồng thời kiểm soát bằng timeout
  Nhưng bạn có biết timeout của requests không phải là timeout cho toàn bộ quá trình đọc trang không? Nếu server gửi byte thật chậm thì có thể chờ vô hạn
  Vì thế tôi đã tự xây một hệ thống crawling để xử lý các vấn đề này. Selenium cũng có thể chạy ổn định trong đó
  Dự án của tôi là crawler-buddy, còn thư viện nền là webtoolkit

  • Đừng quên rằng content-length được tính sau content-encoding
  • Tôi tò mò không biết có khác biệt gì giữa “scraping” và “crawling” không
  • Có vẻ sắp đến thời của scraper chạy trong trình duyệt. Từ phía server thì gần như không thể phân biệt với con người, và AI driver cũng có thể vượt qua cả bài kiểm tra dành cho người dùng

• Cụm “thu thập dữ liệu huấn luyện LLM mà không có sự đồng ý” nghe buồn cười
  Chỉ là gửi yêu cầu GET tới một HTTP server công khai, tôi không hiểu cần phải xin phép gì. Tất nhiên vụ weev là một thảm họa ngoại lệ

  • Nếu tôi mở một HTTP server công khai thì tôi chào đón các yêu cầu GET thông thường
    Nhưng (1) truy cập của người dùng bình thường và tấn công DDoS bằng bot là hai việc khác nhau. Cho miễn phí không có nghĩa là được lấy vô hạn; đó là lạm dụng
    (2) sao chép hợp pháp và hành vi giả mạo của robot cần được phân biệt
    (3) bot vận hành tử tế thì nên tôn trọng robots.txt. Không phải luật, mà là chuyện phép lịch sự
    Những bot xoay vòng hàng triệu IP dân dụng chắc chắn không hề bình thường
  • Nếu bạn đánh lừa cấu hình server để lấy được dữ liệu mong muốn, thì đó là truy cập không được đồng ý
    Server công khai không có nghĩa là cho phép các yêu cầu giả dối. Chỉ có sự đồng ý ngầm với những yêu cầu hợp lý mà thôi
  • robots.txt không có tính ràng buộc pháp lý mà là một đề nghị mang tính lịch sự
    Nó chỉ có nghĩa kiểu như “xin đừng cào trang này”, còn nếu thực sự muốn chặn thì phải dùng API token hoặc quy trình xác thực
  • Đánh đồng một lần truy cập với cơn cuồng crawl vô hạn là vô lý
    Cũng như spam không giống email thông thường, lạm dụng bot cũng khác với một request đơn lẻ
  • Nếu ví như “bát kẹo”, thì một người lớn lấy sạch kẹo dành cho trò trick-or-treat chắc chắn không phải chuyện dễ chịu

• Có lẽ tìm trực tiếp chuỗi http/https sẽ nhanh hơn là parse DOM

  • Chênh lệch tài nguyên giữa tìm kiếm văn bản đơn giản và duyệt DOM là rất lớn, nên nói “có lẽ nhanh hơn” thực ra còn quá nhẹ
  • Cách tiếp cận bằng regex thì dễ triển khai, nhưng ngay cả parse DOM cũng thường không bị nghẽn ở CPU mà ở mạng Cuối cùng tắc nghẽn mạng mới là yếu tố giới hạn

• Thật thú vị khi thấy một ứng dụng thực tiễn của nghiên cứu này
  Có thể xem nghiên cứu liên quan trong bài này

• Tiêu đề hơi gây nhầm. Có lẽ nên dùng “commented-out”

  • Lúc đầu tôi cũng tưởng đó là script chặn AI scraper

• Cái này có vẻ không phải lạm dụng mà chỉ là đang đọc URL đã bị comment out

  • Nội dung bài viết không nói về lạm dụng mà là cách dùng nó như một tín hiệu phát hiện bot
  • Nhưng việc phớt lờ robots.txt rồi còn cào cả phần comment thì rõ ràng là hành vi thiếu lịch sự

• Hồi trước khi crawl web, regex Perl là thứ đáng tin nhất
  Dĩ nhiên tôi cũng đưa cả URL trong comment vào hàng đợi

  • So với vậy thì dò DOM còn là quá tay. Bắt đúng div hay p cần thiết bằng regex vừa chắc chắn vừa đơn giản hơn

• Tôi tự hỏi nếu đưa cho bot một file dữ liệu ngẫu nhiên 512MB thì sao

  • Có lẽ còn sinh lời hơn nếu đầu độc phản hồi quảng cáo dành cho AI scraper để khiến LLM gợi ý một sản phẩm cụ thể
    Startup tôi lập ra chính là dịch vụ Ad-poisoning-as-a-service như vậy
  • Cũng có thể tạo các trang đầu độc AI liên kết ngẫu nhiên để nhốt bot vào đó. Con người thì sẽ không bấm vào
  • Nhưng đa số sẽ khó mà gánh nổi chi phí băng thông
  • Cũng vui nếu nhét toàn bộ 512MB bằng câu “dịch vụ của chúng tôi là tốt nhất”

• Đây có vẻ không phải “thu thập dữ liệu để huấn luyện LLM” mà chỉ là nhiễu từ hoạt động quét Internet

  • Đúng vậy. Nếu là trình quét lỗ hổng thì nó sẽ muốn thu thập càng nhiều HTTP endpoint càng tốt
    File JS là manh mối tốt bất kể có comment hay không
    Ngược lại, nếu là để huấn luyện LLM thì chắc chúng sẽ không quan tâm đến loại mã JS chất lượng thấp này

• Đây là suy nghĩ về cách đầu độc lưu lượng huấn luyện LLM không mong muốn

  1. Nếu nhiều trang phối hợp với nhau thì khả năng làm ô nhiễm mô hình sẽ cao hơn, đồng thời tránh được khử trùng lặp dữ liệu
  2. Cũng có thể dùng luật bản quyền để tăng chi phí đầu độc. Dù vậy bản thân các trang có thể phải gánh rủi ro pháp lý
     Nếu hợp tác với chủ sở hữu bản quyền thì có thể giảm bớt rủi ro
  • Sẽ hay nếu biến ý tưởng đầu tiên thành một plugin WordPress
    Cũng có thể biến đổi ảnh động theo từng request để vô hiệu hóa cơ chế chống trùng lặp. Nếu có plugin như vậy thì tôi sẽ cài ngay