- Trafik scraper AI mengguncang biaya dan stabilitas wiki publik, dan tanpa mitigasi dapat memakai sumber daya komputasi sekitar 10 kali lebih banyak daripada seluruh aktivitas manusia
- Bot kini melampaui User Agent yang mudah dikenali seperti GPTBot, dengan menyamarkan header agar tampak seperti Chrome terbaru dan menghindari pemblokiran lewat proxy residensial yang memutar 1 juta IP per hari
- Wiki mengekspos URL revisi lama, layar edit, dan halaman khusus jauh lebih banyak daripada artikel, sehingga crawling naif dapat melewati cache dan menjadi 50–100 kali lebih mahal daripada permintaan biasa
- Cloudflare Challenge, Anubis, firewall manual, dan deteksi berbasis permintaan perilaku manusia memang efektif, tetapi juga menimbulkan false positive, beban pemeliharaan, dan friksi bagi pembaca
- Pemblokiran ekstrem seperti mewajibkan login atau memberi challenge ke semua trafik bisa mengurangi kontribusi baru, sehingga dibutuhkan diskusi terbuka antar operator dan pendekatan API yang mengubah insentif pengumpulan data bot
Beban yang ditimbulkan scraper AI pada operasional wiki
- Scraping bot untuk data pelatihan LLM meningkat pada skala yang belum pernah terjadi sebelumnya dan mengguncang biaya serta stabilitas situs web publik: masalah terkait juga dibahas di FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline?, dan Smart TV web crawler AI
- Weird Gloop meng-host wiki game besar seperti Minecraft Wiki, OSRS Wiki, dan League Wiki, dan selama tiga tahun terakhir makin banyak menghabiskan waktu untuk menangani trafik bot
- Tanpa mitigasi terus-menerus, bot dapat memakai sekitar 10 kali lebih banyak sumber daya komputasi dibanding seluruh sisanya, termasuk puluhan juta pageview manusia dan puluhan ribu edit per hari
- Wikimedia Foundation juga menerbitkan tulisan tentang dampak crawler pada operasional, wiki farm besar mengalami gangguan dengan tingkat yang berbeda-beda, dan beberapa wiki independen kecil bahkan benar-benar offline
- Diperkirakan sekitar 95% masalah server di ekosistem wiki tahun ini disebabkan oleh scraper buruk
Scraper yang berusaha terlihat seperti manusia
- Bot “resmi” dari perusahaan AI besar seperti GPTBot, ClaudeBot, dan PerplexityBot kadang pernah gagal mematuhi robots.txt, tetapi biasanya masih bisa dikenali dari string User Agent sehingga mudah diblokir lewat pemblokiran bot AI Cloudflare atau nginx
- Setelah webmaster mulai memblokir scraper AI berdasarkan User Agent, bot punya insentif kuat untuk menyamar sebagai trafik manusia
- Sebagian besar trafik scraper AI yang belakangan mencapai wiki mengirim header yang dibuat agar tampak seperti Google Chrome terbaru dan menyusun request dengan cermat
- Sinyal jelas “bot atau manusia sungguhan” yang dulu ada kini menghilang, sehingga pemblokiran jadi lebih sulit
Puluhan juta IP dan penghindaran lewat proxy
- Sebelum 2023, sekitar 95% scraping bermasalah berasal dari satu alamat IP atau subnet pusat data kecil, sehingga pemblokiran berbasis IP atau karakteristik ISP umumnya efektif
- Dengan memakai proxy residensial, pelaku bisa mencuci request scraping melalui jaringan jutaan alamat IP hanya bermodalkan kartu kredit
- Wiki kadang berhadapan dengan scraper yang berputar melalui 1 juta IP per hari, dan trafiknya tampak seperti request sah dari ISP residensial seperti Comcast, AT&T, dan Charter
- Pelanggan terkait kemungkinan besar tidak tahu bahwa IP mereka dipakai sebagai node keluar proxy residensial
- Beberapa pelaku jahat juga memakai pratinjau tautan facebookexternalhit atau Google Translate agar request terlihat datang dari server Google/Facebook dan menyamarkan sumber aslinya
- Dalam beberapa kasus, 99,99% request yang masuk lewat alat URL Google Translate bersifat menyalahgunakan, sehingga sempat perlu merusak alat itu di semua wiki
Crawling “URL bodoh” yang sangat mahal bagi wiki
- Banyak scraper AI memilih URL dengan cara mengunjungi beranda wiki, lalu semua tautan di halaman itu, lalu semua tautan di halaman-halaman berikutnya
- Mereka tampaknya tidak menyadari bahwa robots.txt dan sitemap sudah memberi tahu URL mana yang layak discrape
- OSRS Wiki memiliki sekitar 40 ribu artikel, dan URL inilah yang memuat sebagian besar informasi berguna di situs
- Namun jika memasukkan revisi lama, layar edit, dan halaman khusus, jumlah URL yang bisa dijelajahi mencapai setidaknya 1 miliar
- Crawling naif seperti ini tidak pernah selesai, dan tampaknya menghabiskan banyak sumber daya pada URL yang tidak berguna sebagai data pelatihan LLM
- Request aneh meningkatkan biaya layanan karena melewati lapisan cache seperti MediaWiki parser cache, yang biasanya dipakai request pengguna nyata
- Request dengan cache hit biasanya diproses dalam kurang dari 20 milidetik, tetapi request seperti diff lama sering memakan 1–2 detik
- Metrik tingkat atas seperti “8 juta request bot per hari” atau “bot memakai 65% bandwidth” justru meremehkan masalah
- Bottleneck sebenarnya biasanya kapasitas CPU, dan request bot dengan parameter query aneh sering kali 50–100 kali lebih mahal untuk diproses daripada request biasa
Lonjakan trafik yang tak terlihat dari metrik rata-rata
- Request bot bulanan sekitar 250 juta, atau rata-rata sekitar 100 request per detik, tetapi itu hanya rata-rata jangka panjang
- Scraper sering mengirim lebih dari 1.000 request per detik dalam waktu singkat, sehingga hampir tidak bisa dibedakan dari serangan DDoS tradisional
- Walau dalam jangka panjang bot mungkin hanya menyumbang sekitar 50% dari total penggunaan CPU, lonjakan trafik jahat menyebabkan sekitar 95% perlambatan dan gangguan pada wiki
Struktur yang membuat pelakunya sulit diketahui
- Trafik ini disebut “scraper AI”, tetapi karena semuanya menyamar seperti Google Chrome, sulit mengetahui siapa pihak yang sebenarnya bertanggung jawab atau untuk apa data wiki dipakai
- Pihak yang mungkin terlibat bisa berupa broker data, pengumpulan duplikat oleh frontier lab, atau proyek independen yang punya akses ke proxy residensial
- Seberapa rendah hambatan masuknya pun masih belum jelas
- Jika ada cara yang lebih baik, mereka ingin bisa menghubungi pihak yang benar-benar mengumpulkan data dan mencari metode yang lebih sedikit inefisiensinya
Respons yang sejauh ini efektif
-
Cloudflare Challenge dan Anubis
- Menaruh situs di belakang Cloudflare challenge atau alat seperti Anubis menjadi jauh lebih umum di internet dalam setahun terakhir
- Sampai tingkat tertentu langkah ini efektif, tetapi ada masa ketika sebagian bot terus berhasil melewati challenge
- Tampaknya ada perlombaan senjata tak terlihat antara Cloudflare dan pengembang bot; Cloudflare menang sekitar 90%, tetapi 10% sisanya tetap menjadi bagian yang menyulitkan operasional
- Pembaca nyata tidak suka melihat challenge sebelum bisa mencapai wiki
- Agar tidak memengaruhi kebanyakan orang, dibutuhkan aturan heuristik yang baik untuk menentukan trafik mana saja yang perlu diberi challenge, tetapi mendeteksi trafik otomatis dengan andal sendiri sudah sulit
-
Aturan firewall manual
- Sebagian besar operator memiliki aturan firewall manual yang disesuaikan dengan infrastruktur dan riwayat serangan mereka
- Filter semacam ini biasanya didasarkan pada string User Agent, grup IP, atau ASN tertentu
- Weird Gloop menangani sebagian besar ini di level Cloudflare/CDN, tetapi wiki lain ada yang menanganinya di sisi nginx atau web server
- Saat ini, User Agent/IP saja sering tidak cukup, sehingga perlu melihat properti request yang lebih kompleks seperti versi HTTP, header, cipher TLS, dan hash terkait ja4
-
Mencari “hal yang dilakukan manusia tetapi tidak dilakukan bot”
- Sudut pandang yang berguna adalah mencari perilaku yang dilakukan manusia secara kolektif tetapi tidak dilakukan bot
- Pada wiki berbasis MediaWiki, ada beberapa jenis request HTTP yang sering dibuat pengguna browser nyata saat memakai wiki, dan bot biasanya tidak membuatnya
- Jika sekumpulan trafik yang bisa dipisahkan lewat header, hash ja4, dan sebagainya mengunjungi banyak artikel tetapi tidak membuat request “manusia” yang khas, itu menjadi sinyal kuat untuk menerapkan challenge pada trafik tersebut
- Melihat permintaan perilaku manusia yang tidak ada dalam trafik bot adalah pendekatan yang kuat
- Mereka mulai membangun sistem yang menganalisis trafik yang “hilang” dan otomatis mengusulkan heuristik berbasis decision tree untuk menentukan trafik mana yang perlu diberi challenge
- Dalam pengujian, sistem ini tampak mampu menemukan hampir semua scraper, tetapi belum jelas false positive seperti apa yang mungkin muncul pada orang dengan kebiasaan penelusuran tidak biasa, seperti pengguna NoScript, screen reader, atau perangkat yang tidak terduga
- Membangun dan memelihara infrastruktur ML/analisis data sendiri secara permanen juga tetap menjadi beban
-
Teknik deteksi yang lebih eksotis
Opsi ekstrem yang buruk bagi pembaca
- “Opsi nuklir” untuk menghentikan scraper AI jauh lebih merusak bagi pengguna nyata
- Salah satu cara yang umum adalah mewajibkan login untuk melihat halaman yang biaya pembuatannya bisa tinggi
- Fandom menerapkan langkah seperti ini di semua wiki beberapa bulan lalu
- Cara lain adalah memberi Cloudflare challenge pada semua trafik
- Dari sudut pandang webmaster ini bisa dimengerti, tetapi buruk bagi kesehatan jangka panjang wiki dan komunitas
- Pelajaran inti dari 16 tahun membangun komunitas wiki adalah bahwa cara terbaik menarik kontributor baru adalah menghilangkan friksi
- Perlu membuat pengeditan lebih mudah, memudahkan penjelajahan struktur internal wiki, dan menurunkan hambatan masuk antara pembaca dan editor
- Teknik antibot yang ekstrem menciptakan friksi baru dan menghasilkan akibat yang mudah diprediksi
- Setelah Fandom menyembunyikan “halaman internal” dari lebih dari 95% pembaca tanpa akun, kontribusi pengguna baru di seluruh Fandom dilaporkan turun sekitar 40%
- Sulit menganggap trade-off seperti ini layak
Arah ke depan
- Weird Gloop masih terus meng-host wiki, dan juga terus membantu wiki yang ingin keluar dari Fandom
- Dalam jangka panjang, “AI Overviews” bisa membunuh jalur yang mengubah pembaca wiki menjadi kontributor wiki, tetapi itu dibiarkan sebagai masalah terpisah
- Beberapa kenalan menganggap gelombang bot ini mungkin justru menguntungkan Weird Gloop, tetapi jika orang tidak bisa dengan mudah meng-host wiki, internet akan menjadi lebih buruk
- Skenario di mana hosting wiki yang andal membutuhkan rotasi on-call, engineer ML, dan produk enterprise adalah kabar yang sangat buruk bagi komunitas wiki independen
- Perlombaan senjata antara pemilik bot dan webmaster kemungkinan akan terus berlanjut sampai muncul cara cerdas untuk mengubah insentif struktural dari scraping
- Crawling API baru dari Cloudflare bisa mengubah situasi jika memakai API lebih mudah bagi bot daripada membuat sistem sendiri yang mengabaikan robots.txt dan menimbulkan masalah
- Akan lebih baik jika scraping tidak terjadi sama sekali, tetapi sulit membalikkan apa yang sudah terlanjur terjadi
Perlunya diskusi terbuka dan kerja sama
- Ribuan operator mengelola situs web mereka masing-masing sambil mencari teknik yang lebih cerdas untuk menghadapi bot
- Dalam percakapan privat dengan administrator sistem lain, ada banyak ide bagus dan konkret, dan kemungkinan besar banyak diskusi juga berlangsung di Slack, Discord, dan kelompok kecil
- Diperlukan lebih banyak diskusi terbuka tentang rincian operasional yang nyata
- Banyak administrator sistem belum cukup menyadari bahwa masalah yang mereka hadapi hampir sama dengan operator lain
- Tidak semua orang ingin memublikasikan metode pertahanan mereka sendiri, dan ada juga kekhawatiran bahwa keunggulan akan hilang jika dipublikasikan
- Meski begitu, jika bisa membantu orang saling bertukar pikiran, risiko berkurangnya efektivitas sebagian taktik tetap layak diambil
- Administrator sistem yang menangani scraper AI sebaiknya membagikan metode yang efektif di ruang yang paling sesuai bagi mereka
- Perusahaan yang menjual produk penyelesaian masalah bot seharusnya lebih banyak memublikasikan studi kasus dengan data nyata tentang rasio precision and recall dalam situasi yang tidak direkayasa
- Orang yang membuat keputusan pembelian peduli pada hasil nyata, bukan sekadar mencentang kotak fitur
- Jika Anda mengelola wiki atau situs web independen dan ingin membahas deteksi bot, Anda bisa menghubungi lewat email atau pesan Discord
2 komentar
Pada dasarnya, GeekNews juga didatangi sangat banyak crawler, jadi kami menerapkan berbagai cara untuk memblokirnya dan mengoptimalkan biaya. Bot AI dari Tiongkok benar-benar melakukan crawling dengan tingkat yang sangat parah.
Namun, masalahnya adalah untuk memblokirnya di sisi CDN justru juga menimbulkan biaya.
Pendapat di Lobste.rs
Saya mencoba memakai tantangan proof-of-wait untuk menutupi kekurangan Anubis, dan hasilnya cukup efektif
Pada dasarnya, jika laju permintaan global berada di bawah ambang batas, filternya dimatikan; jika melewati ambang, pengguna harus menunggu N detik sebelum bisa lanjut
Setelah itu, sistem menerbitkan token yang terikat ke IP tersebut, yang hanya mengizinkan sedikit permintaan sebelum masa berlakunya habis, dan token itu sendiri juga diberi pembatasan laju
Jika permintaan yang berhasil terus masuk, waktu tunggunya akan makin panjang
Cukup berhasil, menurunkan performa secara bertahap agar perangkat mobile tidak dirugikan secara berlebihan, dan tetap berjalan tanpa JavaScript
Rasanya hal seperti ini seharusnya berada di lapisan yang lebih bawah, seperti TLS atau bahkan stack IP sistem operasi
Saya belum terlalu memikirkan proof-of-wait, tapi bukankah untuk pengguna sah ini justru terasa lebih buruk daripada untuk scraper otomatis? Manusia kesal karena harus menunggu, sementara scraper cukup menyimpan token lalu kembali lagi setelah N detik
Saya juga punya perasaan campur aduk soal proof-of-work, tapi setidaknya itu membebankan biaya nyata pada scraper yang sebanding dengan skalanya
Proof-of-wait mungkin juga bisa menenangkan orang-orang yang khawatir tentang proof-of-work
Untuk halaman khusus tertentu, cukup efektif juga jika akses hanya diizinkan bagi klien yang sudah login sekali dan memiliki cookie terkait; jika tidak, langsung ditolak
Karena kebanyakan crawler membidik halaman khusus saat menyapu wiki, halaman-halaman itu bisa dibatasi hanya untuk pengguna yang login
Dalam konfigurasi ini, wiki tidak mengizinkan pembuatan pengguna
<If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
ErrorDocument 403 "Access denied, please login."
Require all denied
</If>
Ini sangat mengurangi beban sistem kami. Sebelumnya, sering ada lonjakan ketika halaman khusus dirayapi secara agresif sampai wiki nyaris tak bisa dipakai
Selain itu, kami langsung memblokir user-agent crawler AI yang sudah dikenal dengan 403, dan juga memblokir rentang IP tertentu seperti Alibaba atau Amazon Cloud
Menariknya, pihak sana menyadarinya. Mereka menyapu halaman lewat tampilan Diff, lalu ketika dibatasi mereka mencoba hal yang sama lewat tampilan MobileDiff
Sempat saling balas beberapa kali, tapi sejak beberapa bulan lalu metode ini berjalan lancar
Jika Anda memblokir berdasarkan user-agent, crawler akan mencoba lagi dengan user-agent yang tampak seperti manusia untuk menjelajahi situs
Jika mereka menyimpulkan bahwa pemicunya adalah user-agent, mereka masuk ke mode neraka, jadi jauh lebih sulit diidentifikasi dan akan menghantam situs sampai mati
Pemblokiran rentang IP juga membantu, tapi tidak cukup karena mereka merayapi lewat proxy malware mobile, jadi tidak bisa menangkap semuanya
Kalau sejak awal tidak diblokir, biasanya mereka tetap relatif jinak
Jadi triknya bukan memblokir, melainkan memberi mereka data sampah murah yang tidak memicu mode neraka, dan saya memakai https://iocaine.madhouse-project.org/
Hanya saja, kalau begitu MediaWiki harus melayani responsnya sendiri, jadi ada juga keuntungan bila ditangani di Apache
Sedikit menyimpang, tapi Weird Gloop adalah layanan yang luar biasa. Kualitas wiki yang mereka operasikan sangat tinggi, dan memindahkan konten buatan penggemar dari platform Fandom yang mengerikan adalah hal yang baik bagi dunia
Gergely Nagy, a.k.a. algernon, sekaligus pengembang iocaine, sudah menangani masalah ini selama beberapa waktu dan kemungkinan punya wawasan yang berguna untuk Weird Gloop
Saya benci mengatakannya, tapi usulan untuk menyetel berdasarkan perilaku manusia rasanya akan berbalik menggigit di kemudian hari
Bot pada akhirnya akan mulai meminta semua aset statis halaman juga, dengan asumsi bahwa itu bagian dari perilaku yang mengidentifikasi manusia
Permainan yang menarik, Profesor Falken
Jika scraper mencapai halaman seperti ini dengan mengikuti tautan
<a href=...>biasa secara rekursif, saya rasa mungkin kita bisa dengan halus mengarahkannya ke tempat lain dengan membuat halaman mahal dan tidak bisa di-cache seperti diff riwayat hanya bisa diakses lewat submit<form method="POST" action=...>Tidak ada yang diblokir, dan ini pada dasarnya juga menguntungkan dari sudut pandang scraper karena mencegah mereka menelan informasi duplikat yang nyaris tak terbatas secara rekursif
Pengguna biasa pun mungkin hampir tidak merasakan perbedaannya, dan rasanya efektif dibanding usaha yang dibutuhkan. Untuk pengguna anonim, ini mungkin lebih baik daripada Anubis
Ini bergantung pada asumsi bahwa scraper tidak mengirimkan form HTTP dengan
method="POST"Jika itu umumnya tidak benar, rasanya kita pasti sudah melihat headline bahwa scraper AI mengirim edit anonim massal dan mengubah isi Wikipedia menjadi sampah acak
Saya penasaran apakah bot akan menekan
<form method="GET">juga. Ini akan lebih cocok dengan cache dan tetap bisa menuntut logika tambahan dari crawler95% trafik blog kecil saya datang dari scraper LLM dari Singapura dan China
Sudah bertahun-tahun berlalu, masa belum ada yang menelusuri IP dan menghubungi lalu mendatangi salah satu ISP kecil yang bisa dicari secara langsung? Belum ada yang dengan sopan bertanya kepada pengguna itu apakah komputernya boleh diperiksa? Belum ada yang benar-benar menemukan perangkat lunak apa yang melakukan crawling?
Kalau operator situs tidak bisa melakukan hal seperti ini, saya jadi tak mau peduli lagi. Mereka mendapat bot karena mati-matian menghindari kontak antarmanusia yang kotor di dunia nyata
Dan bot yang berjalan di botnet residensial tentu kadang punya sumber daya komputasi cukup untuk lolos CAPTCHA atau Anubis
Tidak mungkin menang permanen dari sisi server. Pengguna komputer itu juga menghasilkan trafik yang sah
Jadi kecuali Anda menginginkan attestation jarak jauh, Anda harus mendatangi IP-IP itu
Bahkan tanpa menghitung masalah nyata seperti ongkos bensin untuk keliling dunia, ini menjadi travelling salesman problem yang luar biasa besar
Gagasan bahwa karena beberapa bot, admin sistem harus menghabiskan akhir pekan menyetir ke mana-mana agar mereka sedikit lebih sopan, apalagi mengingat kebanyakan berasal dari ISP besar atau ISP asing, sungguh cuma menggelikan
Rasanya sampai ingin tahu Anda habis pakai apa
Soal perangkat lunak apa yang melakukan crawling sekarang? Seseorang menyuruh chatbot, “buatkan sesuatu untuk men-scrape ini,” lalu tiap scraper dibuat secara terpisah
Kalau tidak, itu cuma menyalahkan alam semesta secara abstrak
Saya jamin kebanyakan penyedia layanan sama sekali tidak peduli IP mereka dipakai untuk men-scrape situs web mana
Dan saya juga yakin mereka tidak akan pernah memberi tahu alamat yang terhubung ke IP tersebut
Yang jauh lebih efektif adalah membuang seluruh trafik ASN yang terkait dengan berbagai penyedia seperti Alibaba atau AWS
Ini bukan selalu pilihan yang memungkinkan. Misalnya, kalau blog memiliki feed Atom, pembaca feed juga bisa ikut terblokir
Tapi dalam banyak kasus, ini bisa menghilangkan 80% trafik sampah
Adakah yang tahu mengapa perilaku seperti ini terjadi? Saya terutama penasaran kenapa ada lonjakan
Saya tidak tahu apakah itu benar, tapi setidaknya terdengar masuk akal
Sulit mengatakannya tanpa pemahaman yang lebih baik soal infrastrukturnya. Bisa juga keterbatasan command-and-control
Jika botnet awalnya dibangun untuk DDoS, mungkin secara struktur memang kurang cocok untuk kontrol yang rinci